BOnjour,
Je souhaiterais savoir ce qu'apporte Entity Framework par rapport à Hibernate car pour pour le moment, je ne vois pas vraiment de différence dans tous les articles que j'ai lu.
Je vous remercie de votre aide.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Difference entre Entity Framework / Hibernate.
BOnjour,
Je souhaiterais savoir ce qu'apporte Entity Framework par rapport à Hibernate car pour pour le moment, je ne vois pas vraiment de différence dans tous les articles que j'ai lu.
Je vous remercie de votre aide.
-Intégration de Linq
-Des outils pour faire le mapping très performant et bien intégré a visual studio
-Ce n'est pas uniquement pour les base de données et a terme peut etre utiliser pour se mapper à n'importe quel type de source de donner
- c'est une base d'acces au données qui sert a d'autres outils très intéréssant comme par exemple astoria
- une orientation plus RAD
- Certaine option de tracking des modification (mais moi j'aime pas mais d'autres si)
Je pense qu'il y a d'autres choses j'ai pas encore utiliser sur un projet de A a Z
Après tout n'est pas rose et nhibernate a aussi des avantages comme le fait d'être "Persitance Ignorant" ou encore d'avoir un cache plus configurable
Pour faire l'avocat de NHibernate :
* Plus abouti (car plus ancien)
* Très utilisé, compatible avec beaucoup de solutions tierces
* Une communauté beaucoup plus importante
J'ai découvert EF très récemment, mais il semble que Microsoft va le pousser en avant : "We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios."
Traduction : nous investissons beaucoup dans l'Entity Framework, afin que ce soit la solution compatible LinQ recommandée pour tout ce qui est accès aux données dans .Net 4.0.
Source : ADO.Net team blog, 29 oct 2008
http://blogs.msdn.com/adonet/archive...s-roadmap.aspx
Sinon pour ceux qui voudraient un aperçu technique de Entity Framework, je conseille vivement le tutoriel de Paul Musso tutoriel de Paul Musso
De ce que je me rappelle, tu as surtout une difference de philosophie entre les deux...Envoyé par gregb34
Apres, effectivement, de ce qu'il me semble, NHibernate est, a l'heure actuelle, toujours le plus abouti des deux
Au niveau du mapping, si je me rappelle bien, tu as un tres joli outil de mapping graphique pour EF, mais je crois que le revers de la medaille, c'est une impossibilite de faire des merge efficaces au niveau du controleur de code source (et puis de toute facon, tant qu'on bossera avec VS 2005, EF n'est pas une option..)
Si je puis me permettre, pour une meilleure compréhension des choses par les nouveaux arrivants à EF et/ou à NHibernate qui ont besoin de "faire un choix", j'aimerais dire que les réponses à la question initiale sur ce fil sont assez justes à mon avis, mais qu'il y a une dimension à ne pas perdre de vue : les "scopes" (portées) respectives des deux "technologies" ou simplement "librairies" si vous préférez.
En effet, on a coutume de dire qu'il convient toujours d'essayer de comparer ce qui est comparable.
Or, comparer NHibernate (initialement, un portage de l'éprouvé Hibernate Java, qui maintenant évolue avec .NET lui même) et EF, qui semble être une autre brique satellite majeure dans l'arsenal de la plate-forme .NET, à côté de WCF, WF, etc, c'est un peu comparer un ferry avec un paquebot de luxe.
Ainsi, NHibernate (le ferry, qui transporte des gens sur les flots), a été historiquement et reste **dans une large mesure** un **ORM** : "mapper" Objet-Relationnel ; et il remplit très honorablement sa fonction, pour l'avoir mis en oeuvre dans des projets importants, jusqu'en version 1.2. A ce titre, c'est surtout "juste" une librairie parmi tant d'autre, pour répondre au besoin de "mapper" les graphes d'objet .NET avec les "nuages" conceptuels et physiques d'entités-relation que l'on doit gérer du côté de la persistence (SGBD/R, transactionnels ou non).
Je n'ai fait que "jouer" avec EF (le paquebot, plus "luxueux", plus équipé que le ferry) mais j'ai assez vite vu que sa portée est beaucoup vaste :
c'est ce que j'appellerai un "vrai" sous-framework du .NET FX, qui va vouloir titrer parti de beaucoup de choses à la fois : le runtime .NET lui même bien sûr, mais aussi les APIs d'extensibilité dans Visual Studio, les ajouts aux langage C# 3.0 (LINQ), puis C# 4.0, (dynamicité), etc.
C'est pour cela que je vois EF plus comme quelque chose à mettre au même niveau d'indentation que WCF, WF, WPF, etc, qui se veulent tous clairement bcp plus que des librairies, en voulant aussi être des "fournisseurs" interactifs pour l'outil de modelisation dans l'EDI (qu'il soit MS VS, CodeGear, etc) tandis que NHibernate est beaucoup plus "agnostique" quant à l'utilisation qui en est faite dans les outils de développements.
Sauf erreur de ma part, un élément très révélateur est qu'NHibernate n'a par exemple pas (du tout?) besoin de custom attributes pour "fonctionner" (seuls ses fameux mappings ".hbm.xml" suffisent), ce qui est exactement le contraire dans tous ces autres "sous-frameworks" de .NET FX dont EF fait partie.
My two cents.
De ce que je me rappelle, tu as surtout une difference de philosophie entre les deux...
Apres, effectivement, de ce qu'il me semble, NHibernate est, a l'heure actuelle, toujours le plus abouti des deux
Au niveau du mapping, si je me rappelle bien, tu as un tres joli outil de mapping graphique pour EF, mais je crois que le revers de la medaille, c'est une impossibilite de faire des merge efficaces au niveau du controleur de code source (et puis de toute facon, tant qu'on bossera avec VS 2005, EF n'est pas une option..)
Autant pour moi, j'ai omis de préciser pourquoi je considère que c'est revelateur de la difference de portée entre les deux, ce qui n'est à priori pas évident :
NHibernate, pour son boulot de mapping objet-relationnel, fait un usage intensif de System.Reflection et des mappings declaratifs en XML ; et ça lui suffit, parce qu'il n'a pas à se préoccuper de s'intégrer facilement dans un designer visuel de l'EDI hôte ; la durée de vie d'NHibernate c'est seulement le "run time" de l'appli (en tout cas, dans 99% des usages qu'on fait de lui).
en revanche, EF, comme WCF, WPF, WF, ont besoin des custom attributs "marqueurs" pas seulement au run time (pour serialization des graphes d'objets ou autres) mais aussi au moment du design time et du compile time ; au sens strict, les custom attributs ne sont pas absoluments necessaires quand on veut developper de tels frameworks, mais ils sont tres pratiques (car intégrés au langage C# et son compilateur) et "découvrables" par l'EDI visuel au moment ... du design time ou compile time, justement.
(rappelez vous que meme quand vous ne faites que taper du code dans l'editeur C# de VS, ou que vous utilisez un designer, visual studio fait souvent des compilations "en temps reel" a notre insu, ne serait ce que pour les besoins de l'intelli sense ; c'est là que les custom attributes, compilés en catimini rende un IDE visuel comme studio aussi utilisable ; s'il devait se reposer uniquement sur System.Reflection, réputé couteux en tant d'execution CPU, quand bcp de types doivent etre inspectés, visual studio serait... plus lent à reagir en terme d'interactivité ; enfin, de toute façon, les custom attributes rendent l'ecriture des designers / serializers bcp plus faciles, d'une maniere generale ; c'etait un objectif de conception majeur de C# dès sa version 1.0)
"CQFD"
Je me permet de commenter un peu ta réponse, vu que je travaille actuellement sur un projet basé sur EF :
* EF n'est pas encore un paquebot de luxe. Si la version actuelle est fonctionnelle, l'interface graphique pour gérer son modèle mérite encore du travail.
Vivement la prochaine version
* EF ne nécessite pas l'utilisation d'attributs.
Pour être précis : si attributs il y a, ils sont placés tout seuls dans les classes générées par EF. Le développeur ne les voit jamais.
Le principe de base de EF c'est que le développeur créé un modèle (de mapping) qui s'appuie sur sa source de donnée, et EF s'occupe de créer des classes partielles qui contiendront la logique de persistance. du coup le code du développeur est très épuré puisque qu'il ne contient que le code du développeur et rien d'autre (pas même un attribut).
C'est effectivement une différence majeure avec NHibernate qui travaille essentiellement au runtime (comme le disait très justement lysiandad)
* Un inconvénient majeur (à mon sens) de cette classe générée, c'est qu'on ne peut pas lui définir d'héritage. Elle hérité déjà d'une classe du framework EF, ce lui fait perdre un peu de souplesse.
ex : pour implémenter son propre MembershipUser, on doit hériter de MembershipUser donc il faudra coder 2 classes pour le mapper avec sa base en utilisant EF.
* En revanche l'un des développeurs principaux de l'Entity Framework a annoncé qu'ils travaillaient ferme à ne plus forcer cet héritage. On parle de Persistence ignorance.
Detail ici si vous lisez l'anglais
* LinQ + EF ça roxx ! Ca c'est indéniable. Une fois passé la frustration de ne pas pouvoir faire d'héritage maison sur ses ptites entités, et après avoir galéré sur l'interface graphique, ce n'est plus que du bonheur.
Ma seule interrogation, c'est pour le travail en équipe. Je n'ai pas encore testé ça sur un projet multi-développeurs, à voir.
Ah, merci pour ces précisionset j'avoue que j'avais manqué de voir cette prise de conscience (cf votre lien) de l'équipe EF pour aller vers une implémentation EF dans l'esprit "POCO", plutôt que implémentation avec classes de base "intrusives".
Je pense en effet que c'est une bonne nouvelle, la bonne approche, même si, afin d'éviter le hors sujet, je ne vais donner ici mes arguments dans cette direction, que je ne fais que partager avec bcp d'autres par ailleurs de toute façon (il suffit de "googler" pas plus de 2 minutes sur les nombreux articles en faveur de l'approche POCO (C#) ou POJO (Java) sur les strategies de conception des frameworks).
Ok, vu : donc, effectivement les custom attributes EF sont transparents pour le design time (puisque générés dans du code que le développeur n'ira pas retoucher à priori), ce qui confirme qu'ils sont surtout là pour faciliter le boulot au run time d'EF, très probablement pour des raisons de performances d'execution de la serialization, des lookups, etc.
Pour ce qui est de l'impact sur les processus de travaille en equipe, je vous rejoins entierement : il y aura probablement des etudes interessantes a faire (a posteriori) sur les travers insoupçonnés (en clair, les "frottements" générés dans les plannings projets, pendant le developpement d'applis pas du tout triviales / importantes utilisant EF, genre... à partir de plus de 100 et quelques classes "feuilles" liées au métier) ... ce qu'on ne manquera pas de faire tot ou tard, je suppose.
En guise d'epilogue a mes precisions et les votres, on (je, en tout cas) ne repetera jamais assez le "genie" si on peut dire d'Anders et les autres chez MS d'avoir une fois pour toute introduit au sein du runtime (CLR) et de la syntaxe du langage source (C#, VB.NET, etc) ces metadata, elles-memes orientees objet (puisque classes a part entiere) qui ont donné lieu à tant de cas d'utilisation differents. Sur ce coup la, ils ont vraiment vu juste... meme Java a fini par s'y mettre...
Bon certes, le concept de metadata n'etait clairement pas nouveau en informatique logicielle, y compris en 99/2000 quand MS preparait son bebe codenamed "NGWS" a l'epoque (le ".NET" a venir en release), mais, sauf erreur, c'est la premiere fois que des concepteurs et developpeurs d'un runtime oriente objet, et ceux des langages de la meme veine, et ceux des compilateurs de ces derniers, ont eu l'idée et ont assumé jusqu'au bout (y compris dans les 1eres specs) ce choix.
Presque 10 ans après, ma foi, je suis tenté de dire que c'était le bon pari, non ?
Répondre avec citation
Vous voulez contribuer à la rubrique .NET ? Contactez-moi par MP.
Partager