Les attributs de cartographie offrent la même polyvalence que celle de Nib HBM? Pouvez-vous les utiliser avec FNH pour gérer les choses que FNH ne font pas encore ainsi que la boîte de HBM?
acclamations,
Berryl
Par attributs de mappage, je ne veux pas dire des fichiers HBM; Il existe apparemment des attributs qui sont livrés avec NIHH (ou peut-être des contributions NIhib ces jours-ci) que vous utilisez pour décorer vos propriétés de classe et de classe. Je suppose que ces pré-date FNH, mais pas sûr.
6 Réponses :
Je n'ai jamais rencontré une situation qui ne pouvait pas être traitée par Nibernate fluide, mais peut-être que vous utilisez un attribut obscur. Tout ce que vous avez besoin de savoir est disponible?
Je n'utilise actuellement que FNH aussi et je ne connaissais même pas les attributs de cartographie jusqu'à ce que la question de Manning Nhib in Action est donc davantage à leur sujet que FNH. Mais une chose que j'ai des problèmes avec FNH, c'est que cela ne me permettra pas de définir des noms de colonne et des valeurs de la colonne discriminator (il utilise des défauts qui fonctionnent, mais ne sont pas ce que je veux). Acclamations
BERRYL, je pense que vous devez soulever une question de soutien sur votre problème de discriminator, car les FNH vous permettent de spécifier à la fois le nom de la colonne et les valeurs de discriminator.
@James - En fait, j'ai soulevé une question de soutien, je n'ai aucune réponse et a vu d'autres postes sur le même numéro d'autres utilisateurs depuis. Voir le numéro de soutien soulevé le 26 mars 2010 @ 11:07 "Conversion de table-Per-Subclass en table-par-classe-Heirachy" (2e post) et ce fil groups.google.com/group/fluent-nibernate/browse_thread/thre annonce / ... a commencé le 9 mars. Acclamations
Je préfère personnellement créer moi-même les fichiers hbm.xml. J'ai utilisé couramment, mais j'aime bien gérer le Nitty Gritty moi-même pour des choses comme celle-ci. Cependant, je n'ai rencontré aucun mappage que je n'ai pas été capable de travailler avec couramment ...
Je crois comprendre que Nibernate fluide crée en fait un fichier hbm.xml en arrière-plan en fonction de vos paramètres utilisés par NHibernate ... Donc, comme celui-ci crée elle-même les mappages, je dirais que juste créer Le HBM.XML manuellement vous donnerait techniquement plus de flexibilité et d'accès à la nuance du fichier de mappage ...
Je pense qu'il existe une courbe d'apprentissage similaire pour les deux, donc si vous allez déranger l'apprentissage fluide qui crée lui-même des fichiers HBM.XML, pourquoi pas seulement apprendre à créer vous-même la création des fichiers DAMN HBM.XML en premier lieu. et sautez l'homme du milieu!
sauf si vous faites de nombreux projets de succession rapide, l'acte de mapper votre base de données n'est qu'un fragment du travail réel que vous effectuez sur un projet particulier.
D'accord. Le XML-O-phobic en moi a résisté à l'apprentissage de HBM, mais vous ne parleurez pas vraiment avant de le faire. Je parle des attributs qui constituent une alternative ou des fichiers FNH et HBM. Acclamations
Max: Alors pourquoi ne pas écrire vous-même brut vous-même? C'est tout NHibernate génère à la fin. C'est l'abstraction qui vous profite dans le cas de NHibernate et des mappages de FNH. Bien sûr, tous les FNH génèrent des HBMS, mais il simplifie également le processus de le faire et vous donne un meilleur contrôle à un niveau supérieur. Je suis tout à fait d'accord que la cartographie est une infime partie d'un processus de développement d'applications, mais il vaut sûrement mieux de faire une quantité plus petite ?
Je pense que cela se résume à choisir vos abstractions. La partie SQL est une pièce majeure et NHibernate permet d'économiser de temps significatif sur l'écriture de SQL, mais pour la cartographie, je ne sais pas ... J'aime la manifestation fluide pour un échafaudage rapide, mais je ne suis pas d'accord sur le meilleur contrôle. Si la loi des abstractions fuites est vraie, et avec la fluence, une abstraction d'une abstraction, ma préférence est de se rapprocher de l'approche métallique si possible. Je suis aussi à l'aise avec le HBM.XML et je ne les trouve pas plus complexes que couramment. Ses instructions juste différentes pour obtenir le même résultat.
Les attributs de NHibernate font de la pré-date FNH. En dehors d'un groupe relativement petit de hauts détérieurs, je ne connais pas vraiment personne qui les utilise. Ils sont soutenus, mais pas exactement sympathique. Si vous aimez les attributs, le Les attributs de Castle Activerecord sont une bien meilleure mise en œuvre que les NHibernate CORE.
Nibernate fluide peut fonctionner avec tout le reste. Tout ce que cela fait, c'est injecter des mappages dans l'instance de configuration NHibernate, vous pouvez donc mettre l'autre autre dans votre apparence. ActionCord est un peu plus une solution à grande portée, ce qui peut être une exception à cette règle, cela fait longtemps que je l'ai utilisé.
C'est ce que je pensais. "Nhib in Action" leur donne de l'air significatif et donc de la crédibilité, tout en disant que FNH est un travail prometteur en cours, ce qui a d'autres experts Nibhants comme Ayende, Fabio & Steve Bohlen semblent à dire quand ils dis-le. Bien que le livre soit clairement daté de détails, la portée qu'elle couvre est plus sophistiquée que tout ce que j'ai vu jusqu'à présent. Je ne sais pas comment combler mes lacunes de connaissances autres que en posant des questions "muettes" ici sur les forums de SO et NIH / FNH. Nature de la bête compliquée imo, mais vous remplissez clairement une lacune dans la communauté qui est appréciée par beaucoup. Acclamations
Une chose que vous devez nue à l'esprit est que NHibernate d'action a été publiée il y a plus d'un an, le contenu congelé un peu avant cela et sur la base des versions de Nibernate 1.x. Bien que cela n'affecte pas la qualité de son contenu, les lots ont changé depuis.
Aussi de note, NHibernate fluide JAMAIS SOUTOIR Chaque cartographie possible que NHibernate prend en charge, car énormément de ces mappages sont là pour soutenir des cas de bord particuliers. C'est la règle 80/20, nous soutenons les 80% que les gens utilisent le plus, le reste peut toujours être fait dans HBM.
À droite; C'est pourquoi il est raisonnable pour un consommateur de comprendre ce que les 20% manquants sont et de la meilleure façon de le fournir en cas de besoin. La question ici est de voir si les attributs de mappage valent la peine d'explorer comme un moyen de finir. Votre réponse ne serait clairement pas monsieur, faites-le dans un HBM. Acclamations
Nous les utilisons dans mon entreprise et je les aime un peu comme eux.
Je pense que c'est vraiment propre à écrire la cartographie directement dans la définition de la classe (je sais - à chacun la sienne).
Je suis d'accord avec la plupart des commentaires ici, Hibernate vous donne la liberté de choix sur la manière de mettre en œuvre les cartes des objets.
Je préfère ne pas utiliser d'attributs sur mes cours pour NHibernate, comme maintenant mes classes ont maintenant une autre dépendance qu'ils ne devraient pas savoir.
Que se passe-t-il si vous souhaitez modifier votre DataSORCE en une OODB ou juste un fichier. Les classes auront un code de cartographie redondant (les attributs). Dans ce cas, il pourrait être dit, son nettoyant pour stocker le mappage dans la couche de données / infrastructures avec la mise en œuvre du référentiel (utilisation supposée du motif de référentiel)
Je suis également d'accord, chacun de chacun de ses propriétaires :)
D'accord - Je me demandais simplement s'ils offraient plus d'équivalent HBM 'Power' que de FNH, que je vais utiliser pour que les 80% soient effectués dans tous les cas. Sous-jacents, il y a la question de savoir ce que peut faire exactement le HBMS que FNH ne peut actuellement pas. Acclamations
C'est cool, je pensais que vous envisagiez des mappages attribués. Une chose exempue à propos de FNH Il vous permet de convertir votre cartographie fluide dans l'ancien XML, en cas de trouver quelque chose qu'il ne fait pas (FYI que je n'ai pas encore trouvé quelque chose qu'il ne peut pas faire). Je suppose que tu sais ça
J'essaie de comprendre où NHibernate 3 se tient par rapport à Hibernate 3 en ce qui concerne les attributs vs annotation. Je suis sur plusieurs projets Java où nous avons utilisé hibernate 3 annotations pour la cartographie. Il est assez élégant comme
Pas sûr d'acheter le "Et si vous devez changer de données de données" ou les arguments "Séparation des préoccupations". En pratique, ces arguments examinent les "20%" (ou moins) qui ne se produiront pas, ni ont un impact marginal s'ils le font - les avantages sont beaucoup plus importants dans l'OMHO.
Avec cela dit, qu'est-ce qui ne m'appartient pas, c'est si l'équipe NHibernate a investi suffisamment pour rendre les attributs suffisamment robustes pour justifier l'utilisation, ou si je serais mieux de déménager à EF4.x pour obtenir les mêmes avantages ... Ce sont les réponses que j'espérais depuis ce poste.
FNH ajoute toujours beaucoup quels attributs ne peuvent pas gérer: 1) Automapping 2) Conventions (pour auto et manuel) 3) DiscoverableLILity (par interface fluide)