Entity Framework 4 vs NHibernate

.net entity-framework nhibernate orm

Question

On a beaucoup parlé de la première version d'Entity Framework sur le Web (également sur stackoverflow) et il est clair que ce n'était pas un bon choix alors que nous avons déjà une meilleure alternative comme NHibernate. Mais je ne trouve pas de bonne comparaison entre Entity Framework 4 et NHibernate. Nous pouvons dire qu'aujourd'hui NHibernate est le leader parmi tous les ORM .NET, mais pouvons-nous nous attendre à ce que Entity Framework 4 remplace NHibernate de ce poste? Je pense que si Microsoft a vraiment injecté de très bonnes fonctionnalités dans EF4, il peut concurrencer NHibernate, car il intègre Visual Studio, il est plus facile à utiliser et la préférence est toujours donnée aux produits MS dans la plupart des magasins.

Réponse acceptée

EF4 a une réponse clé en main en ce qui concerne le développement à plusieurs niveaux, dans les "entités à auto-suivi". Personne n'a publié de code comparable pour NHib.

NHib possède de nombreuses fonctionnalités qui n’ont pas été mentionnées comme faisant partie de EF4. Ceux-ci incluent l'intégration de cache de second niveau. Il offre également une plus grande flexibilité dans le mappage des héritages, une meilleure intégration avec les fonctions stockées procs / database / SQL personnalisé / déclencheurs, la prise en charge des propriétés de formule, etc. L'OMI est fondamentalement un peu plus mature qu'un ORM.


Réponse populaire

Mise à jour: je n'ai pas utilisé Entity Framework depuis la version 4.0, ma réponse peut donc être obsolète. J'utilise toujours NH ou pur ADO .NET dans mes projets. Et je ne veux même pas regarder ce qui est nouveau dans EF depuis la version 4.0, car NH fonctionne parfaitement.

En fait, il est assez facile de les comparer lorsque vous avez utilisé les deux. Il y a quelques limitations sérieuses avec EF4, je peux en nommer certaines que j'ai rencontrées par moi-même:

Problèmes EF4:

  • Eager Chargement et mise en forme du résultat : Le système de chargement EF4 eager (Include ("Path")) génère un SQL incorrect, avec des boucles JOIN, qui exécutera des milliers (et non pas littéralement) plus lentement pour les relations plusieurs à plusieurs, puis à la main en SQL (c'est effectivement inutilisable).
  • Le matérialisant ne peut pas matérialiser les entités associées : si vous pouvez penser que vous pouvez surmonter le problème précédent en fournissant votre propre requête SQL, vous avez tort. EF4 ne peut pas matérialiser (mapper) les entités associées à partir d'une requête JOIN, il ne peut charger des données qu'à partir d'une seule table (donc, si vous avez Order.Product, SELECT * FROM order LEFT JOIN, le produit initialise uniquement l'objet Order, le produit restera null, pensait que toutes les données nécessaires étaient extraites dans une requête pour les initier). Ceci peut être surmonté en utilisant l'add-on de la communauté EFExtensions, mais le code que vous devrez écrire pour cela est vraiment moche (j'ai essayé).
  • Entités à suivi automatique : de nombreuses personnes affirment que les entités à suivi automatique sont idéales pour le développement à plusieurs niveaux, y compris la meilleure réponse de ce fil. Bien que je n’aie même pas essayé, je peux dire qu’elles ne le sont pas.Toutes les entrées peuvent être falsifiées, vous ne pouvez pas simplement prendre les modifications que l’utilisateur vous a envoyées et les appliquer à la base de données, pourquoi ne pas lui donner des données directes accès de base alors? Quelle que soit la manière dont vous devrez charger les données, l'utilisateur est sur le point de changer de base de données, vérifiez qu'il n'existe pas, ne vérifie pas les autorisations, etc. Vous ne pouvez pas faire confiance à l'utilisateur sur l'état de l'entité qu'il envoie au serveur, vous devrez quand même devez charger cette entité à partir de la base de données et déterminer son état et d'autres éléments. Cette information est donc inutile, de même que les entités à suivi automatique, sauf si vous utilisez un système privé à plusieurs niveaux de confiance pour un usage interne, auquel cas vous pourriez peut-être donner simplement Accès à la base de données. (C’est ce que je pense de ST Entities et de N-tire, je n’ai pas beaucoup d’expérience dans N-Tier, donc ça peut changer, si j’ai mal compris quelque chose ici, commentez-le)

  • Journalisation, événements, intégration de la logique métier: EF4 est comme une boîte noire, il fait quelque chose et vous n'avez aucune idée de ce qu'il fait. Il existe un seul événement OnSavingChanges où vous pouvez définir une logique métier à exécuter avant que quelque chose ne se produise avec DB. Si vous devez appliquer des modifications à des objets métier avant que quelque chose ne se produise, vous devrez creuser dans ObjectStateManager, ce qui est vraiment moche. , le code peut devenir énorme. Si, par exemple, vous utilisez un modèle de référentiel et que vous souhaitez être averti des modifications apportées à la base de données de manière propre, vous aurez du mal à le faire avec EF.

  • Extensibilité: tout le code EF est privé et interne, si vous n'aimez pas quelque chose (et vous n'aimerez pas BEAUCOUP si vous êtes sérieux au sujet de l'utilisation d'EF), impossible de changer cela facilement, en fait, j'en suis sûr. Il est plus facile d'écrire votre propre ORM à partir de zéro (je l'ai fait), puis de faire fonctionner EF comme vous le souhaitez. À titre d’exemple, jetez un coup d’œil à la source EFExtensions, elle est basée sur des méthodes d’extension et différents "hacks" pour rendre EF un peu plus utilisable, et le code est plutôt moche (et ce n’est pas la faute des auteurs, lorsque tout est privé dans EF, c’est le seul moyen de l'étendre).

Je peux continuer à écrire de mauvaises choses sur EF et à quel point il m’a été pénible de travailler avec elle pendant environ 20 pages, et peut-être que je le ferai.

Qu'en est-il de NHibernate? C'est un niveau totalement différent, c'est comme comparer PHP à C #, EF4 c'est comme dans l'âge de pierre, c'est comme si EF avait 10 ans de retard sur NHibernate, mais en fait, Hibernate a été lancé en 2001. Si vous avez du temps libre apprendre et allumer Nhibernate, faites-le.



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow