Entity Framework 4 vs NHibernate [fermé]

mise à Jour: je n'ai pas utilisé le Cadre de l'Entité depuis la version 4.0, donc ma réponse ne peut être dépassée. J'utilise toujours NH ou pur ADO. NET dans mes projets. Et je ne veux même pas regarder ce qui est nouveau en EF depuis 4.0, parce que NH fonctionne parfaitement.

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

EF4 problems:

• Chargement rapide et la forme du résultat : EF4 système de chargement rapide (Include ("Path")) génère SQL incorrect, avec des jointures en boucle , qui exécutera des milliers(pas littéralement) de temps plus lent pour des relations de plusieurs à plusieurs, puis SQL écrit à la main (il est effectivement inutilisable).
• Materializer ne peut pas se matérialiser entités associées : Si vous pensez que vous pouvez surmonter le problème précédent par si vous possédez une requête SQL, vous vous trompez. EF4 ne peut pas se matérialiser (map) entités associées à partir de JOIN SQL query, il ne peut charger des données à partir d'une seule table (donc si vous avez L'ordre.Produit, Sélectionner * de L'ordre JOIN left le produit initialisera seulement l'objet de L'ordre, le produit restera null, pensé toutes les données nécessaires est récupéré dans la requête pour l'initialiser ). Cela peut être surmonté en utilisant EFExtensions communauté add-on, mais le code que vous devez écrire pour c'est vraiment laid (j'ai essayé).

• self-Tracking Entities : beaucoup disent que les entités auto-tracking sont cool pour le développement n-tier y compris la réponse supérieure dans ce fil. Je pensais que je ne les avais même pas essayé, je peux dire qu'ils ne le sont pas.Chaque entrée peut être falsifiée, vous ne pouvez pas simplement prendre les changements que l'utilisateur vous envoie et les appliquer à la base de données, Pourquoi ne pas donner à l'utilisateur un accès direct à la base de données alors? Quelle que soit la façon dont vous devrez charger l'utilisateur de données est sur le point de changer de DB, Vérifiez qu'il exist / not exist do permissions checks etc. Vous ne pouvez pas faire confiance à l'utilisateur sur l'état de l'entité qu'il envoie au serveur, vous aurez de toute façon à charger cette entité à partir de la base de données et de déterminer son état et d'autres choses, de sorte que cette information est inutile, comme le font les entités D'Auto-pistage à moins que vous ne faites un système n-tier de confiance privée pour l'usage interne, dans ce cas, peut-être que vous pourriez donner l'accès à la base de données simple. (C'est mon pensées à propos de SAINT Entités et N-pneu, je ne suis pas très expericned en N-Tier, de sorte qu'il peut changer, si je mal compris quelque chose ici le commentaire)

• Journalisation des Événements, l'intégration de la logique d'entreprise: EF4 est comme la boîte noire, il faire quelque chose et vous n'avez aucune idée de ce qu'il font. Il n'y a qu'un seul événement OnSavingChanges où vous pouvez mettre un peu de logique d'affaires que vous devez exécuter avant que quelque chose arrive avec DB, et si vous avez besoin d'appliquer quelques changements aux objets d'affaires avant que quelque chose arrive, vous devrez creuser dans Objectstatmanager, et c'est vraiment laid, le code peut devenir énorme. Si vous utilisez par exemple le modèle de dépôt et ce qu'il faut savoir sur les modifications apportées à la base de données de la manière clean object, 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), aucune façon vous changerez cela dans la manière facile, en fait je suis sûr que c'est plus facile à Ecrivez votre propre ORM à partir de zéro (je l'ai fait) puis faire fonctionner EF comme vous avez besoin. Par exemple, regardez EFExtensions source, il est basé sur des méthodes d'extensions, et différents "hacks" pour rendre EF un peu plus utilisable, et le code est assez laid (et ce n'est pas la faute des auteurs, quand tout dans EF est privé c'est la seule façon de l'étendre).

je peux continuer à écrire de mauvaises choses sur EF et à quel point il a été douloureux pour moi de travailler avec elle pendant comme 20 pages, et peut-être que je le ferai.

Qu'en est-il de NHibernate? c'est un niveau absolument différent, c'est comme comparer PHP à C#, EF4 est comme à L'Âge de Pierre, C'est comme EF est 10 ans de retard puis NHibernate dans le progrès du développement, et en fait, il est, Hibernate a été commencé en 2001. Si vous avez le temps d'apprendre et d'allumer Nhibernate, faites-le.

voilà le truc. NHibernate et Entity Framework sont vraiment pour deux publics différents, dans mon esprit. NHibernate serait mon choix dans la construction d'un système avec des mappages complexes, des formules, et des contraintes (essentiellement n'importe quoi d'entreprise). Si je voulais me lancer avec un accès simple aux données, J'utiliserais Entity Framework ou LINQ-to-SQL. NHibernate n'a pas une expérience claire de "glisser-déposer" tout comme EF. Les deux ont leurs forces et leurs inconvénients. En les comparant de la pomme à la pomme, franchement, ça ne mène nulle part.

si vous pensez que vous pourriez Un jour vouloir exécuter votre code sur Mono, NHibernate est probablement un meilleur choix peu importe ce que disent les listes de contrôle des fonctionnalités...

Modifier, 8/13/2012:

Entity Framework a été open-sourced, et est maintenant inclus dans Mono à partir de 2.11.3. Cette réponse est maintenant périmée et ne devrait pas être invoquée.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

mon point de vue sur ceci est que EF4.0 est venu un long chemin depuis 1.0 et rattrape Nhibernate dans la fonctionnalité, mais il n'est pas tout là encore.

il est Toutefois Microsoft, hors de la boîte, et de faire 100% de ce que 95% des applications ont besoin pour faire. Cependant, NHibernate fait la même chose depuis des années. Venez version 5.0 ou 6.0 peut rattraper, ou même dépasser NHibernate.

Voici mon conseil -- si vous avez le temps d'apprendre les deux, faites-le. Il y a plusieurs raisons de choisir l'un sur l'autre. Si vous rédigez un code pour une société, il est réaliste de s'attendre à être des employés compétents qui connaîtraient L'EF, car c'est dans tous les livres et ce que les enfants apprennent à l'Université. Si EF va répondre à vos exigences (pensez à celui-ci longtemps et dur avant de juste dire oui), alors c'est une solution parfaitement fine pour l'instant, et dans quelques années, il peut (ok, très probablement va) dépasser NHibernate.

NHibernate est un très produit mature avec quelques années sur EF et fera très probablement tout ce que vous voudriez jamais faire et puis certains. Il a été le meilleur ORM depuis un certain temps maintenant et beaucoup de gens l'utilisent.

je pense que le fait que EF 4 aura la capacité D'utiliser POCO et différé chargement paresseux sera très grand. Je pouvais certainement le voir gagner en traction avec la nouvelle version.

Il est évident tendance "151920920 ğ de plus en plus EF popularité au cours NHibernate, voir l'image.

mes 2 cents: nous utilisons le Fe sur notre client de bureau pour certains écrêtement etc - pas de charges hi. Un NHib sur le côté du serveur-en utilisant des sessions apatrides, la génération hilod et des lots. Is est assez rapide dans l'insertion de messages 3k+en db par seconde. En outre, il est très flexible et supporte beaucoup de dbs, qui est crucial pour notre produit.

Cartographie directement à des procédures stockées avec une combinaison de Linq pour une couche logique semble l'approche la plus facile. Pas de xml. Générer sql uniquement pour les requêtes intéressantes qui sont moins fréquemment utilisées ou ne conviennent pas aux procédures stockées.

Objets charger et stocker grâce à la norme SPs. Cette approche permet l'utilisation de deux connexions sql. Un pour l'accès de classe par SPs (exécuter-seulement les permissions) et un pour un module linq logique qui permet la table directe accès.

choisir entre les ORM's par popularité n'est pas la meilleure chose à faire. J'ai essayé de déménager à EF ces deux dernières années et tout ce que je peux dire c'est, pourquoi j'essaie encore de le faire?

ATM mon point de vue à propos de EF est: "il est fait pour les très petits systèmes de bits minuscules avec pas plus de 3 tables avec moins de 1 relation (0 est mieux)".

Et pourquoi je pense comme ça? 1. Essayez de mettre à jour un graphique déconnecté et voir votre modèle scratch;

1. Essayer de faire TPH avec une profonde hérité des arbres et vous trouverez que vous êtes schackled à une seule hiérarchie ou le système de pause.

2. essayez de faire des requêtes plus encombrantes et regardez l'ensemble du système dévorer la pile: D... des débordements se produisent très souvent.

3. Map les types de données XML sont basés sur des extensions ou les propriétés NotMapped les plus" détesté"... et c'est encore pire.

4. essayez de mélanger la requête SQL dans Linq pour obtenir plus de requêtes finner et vous briserez le mur lol.

5. et la dernière et la plus importante chose, EF ne supporte pas la formule de propriété ('an awesome resources NH has for legacy databases'), et ne supporte pas les mappages de type Complexes pour la même table et les tables connexes.

C'est mon 10cc.