Pourquoi des fichiers XML fluides NHibernate vs. hbm?

Question

Bien qu'il s'agisse d'une question subjective, en tant que nouvel utilisateur de NHibernate, je suis curieux de savoir pourquoi on choisirait le mappage XML courant/fluide. De mon point de vue, lorsque j'ai travaillé pour la première fois avec NHibernate, j'ai utilisé l'interface Fluent, mais j'ai rencontré des obstacles et j'ai eu du mal à trouver une documentation adéquate pour l'interface Fluent. pour gérer ceux-ci via XML. Au fil du temps, j'ai réalisé que je faisais la plupart de mon travail sur le côté XML, et je me suis rendu compte que ce n'était pas aussi horrible que je le pensais. Donc pour moi personnellement, c'était un cas de mauvaise documentation et de ne pas voir d'économies significatives dans le temps de codage. Cela dit, il peut y avoir un énorme avantage/inconvénient qui me manque, et j'aimerais vraiment entendre des opinions de gens qui ont plus d'expérience dans le travail avec ces outils.

Answer 1

La sécurité au moment de la compilation et le refactoring (renommer les classes, les propriétés) sont l'un des avantages des mappages fluides. Utiliser un langage (C# ou VB.NET) pour écrire des mappages, le code de programme et l'accès aux données est un autre avantage.

Answer 2

• temps Compile Nom et type sécurité
• IntelliSense pour vous montrer quelles méthodes couramment sont disponibles à tout moment
• par défaut personnalisable
• Automapper

Answer 3

Comme beaucoup d'ouverture logiciel source, cette bibliothèque était disponible au public avant que beaucoup de fonctionnalités soient prêtes pour la production. Selon la version de FluentNhib avec laquelle vous travailliez, certaines fonctionnalités peuvent ne pas avoir été implémentées du tout. Par exemple, lorsque j'ai commencé à travailler avec elle, les clés composites n'avaient pas encore été implémentées et j'ai trouvé la pierre d'achoppement après la pierre d'achoppement.

Mais le produit a évolué pour devenir un très bon outil. C'est une fonctionnalité assez complète par rapport à xml et fournit tous les avantages déjà décrits par d'autres.

Answer 4

Pour moi, la grande caractéristique de Fluent est l'Automapper.

Je peux définir mon modèle de domaine en utilisant des classes POCO, (la plupart du temps) sans me soucier des détails désagréables de la façon dont ils seront mappés aux tables dans une base de données relationnelle.

En tant que développeur OO de longue date et développeur occasionnel de bases de données, je suis beaucoup plus à l'aise dans la conception OO. Je crois aussi que cela me permet de travailler à un niveau d'abstraction plus élevé et plus puissant. L'automatisation rend également les modifications en cours du modèle de domaine beaucoup moins décourageantes.

Vos clients viennent de vous dire à la dernière minute qu'ils souhaitent ajouter quatre nouvelles colonnes à la base de données?

Aucun problème - ajoutez quatre nouvelles propriétés au POCO associé (4 lignes de code), et remappez.

Prend une grande part de la douleur des exigences en constante évolution qui sont une réalité dans de nombreux projets.

Answer 5

Je vais ajouter une raison qui est très important pour la fabrication de fonctionnalité personnalisée basée sur une base de code commune:

Fluent vous pouvez remplacer les correspondances pour ajouter un nouveau champ. Les modifications apportées aux mappages existants (superclasse) sont automatiquement incorporées dans la personnalisation/branche. J'ai été forcé d'utiliser Fluent pour éviter de conserver un fichier .hbm/xml séparé pour chaque client. Content de l'avoir fait :)