Pendant mon apprentissage, j'ai utilisé NHibernate pour certains petits projets que j'ai principalement codés et conçus par moi-même. Maintenant, avant de démarrer un projet plus important, la discussion a porté sur la manière de concevoir l'accès aux données et sur l'utilisation ou non d'une couche ORM. Comme je suis encore en apprentissage et que je me considère toujours comme un débutant en programmation d'entreprise, je n'ai pas vraiment essayé de pousser à mon avis, qui est que l'utilisation d'un mappeur relationnel objet dans la base de données peut faciliter beaucoup le développement. Les autres codeurs de l'équipe de développement sont beaucoup plus expérimentés que moi, donc je pense que je vais faire ce qu'ils disent. :-)
Cependant, je ne comprends pas complètement deux des principales raisons de ne pas utiliser NHibernate ou un projet similaire:
- On peut simplement créer ses propres objets d'accès aux données avec des requêtes SQL et copier ces requêtes hors de Microsoft SQL Server Management Studio.
- Le débogage d'un ORM peut être difficile.
Donc, bien sûr, je pourrais simplement créer ma couche d'accès aux données avec beaucoup de SELECT
s, etc., mais ici je manque l'avantage des jointures automatiques, des classes proxy à chargement paresseux et un effort de maintenance moindre si une table obtient une nouvelle colonne ou une colonne obtient renommé. (Mise à jour de nombreuses SELECT
, INSERT
et les UPDATE
requêtes contre la mise à jour de la configuration de la cartographie et la refactorisation éventuellement les classes d'affaires et DTO.)
De plus, en utilisant NHibernate, vous pouvez rencontrer des problèmes imprévus si vous ne connaissez pas très bien le framework. Cela peut être, par exemple, de faire confiance au Table.hbm.xml où vous définissez la longueur d'une chaîne pour qu'elle soit automatiquement validée. Cependant, je peux également imaginer des bogues similaires dans une couche d'accès aux données basée sur une requête SqlConnection «simple».
Enfin, ces arguments mentionnés ci-dessus sont-ils vraiment une bonne raison de ne pas utiliser un ORM pour une application d'entreprise basée sur une base de données non triviale? Y a-t-il probablement d'autres arguments qu'ils / j'aurais pu manquer?
(Je devrais probablement ajouter que je pense que c'est comme la première "grande" application basée sur .NET / C # qui nécessitera un travail d'équipe. Les bonnes pratiques, qui sont considérées comme assez normales sur Stack Overflow, telles que les tests unitaires ou l'intégration continue, ne sont pas -existant ici jusqu'à présent.)