J'ai entendu de mauvaises choses sur Entity Framework, et j'envisage de l'utiliser.
- Quelle est votre opinion à ce sujet ?
- Dois-je l'apprendre ?
- Quels en sont les points forts ?
- Quels sont ses points faibles ?
J'ai entendu de mauvaises choses sur Entity Framework, et j'envisage de l'utiliser.
Si vous n'avez jamais utilisé un type de Business Entity ou d'O/RM (comme NHibernate ou LLBLGen), vous ne trouverez probablement pas beaucoup d'inconvénients à Entity Framework. Dans mon entreprise, nous avons évalué les 3 outils, et avons fini par choisir LLBLGen parce que c'était un moyen très facile de travailler directement avec la base de données (plutôt que de passer beaucoup de temps à construire un modèle objet).
Pour une raison quelconque, il était plus facile pour nous de commencer avec notre modèle de données et de le construire (l'approche LLBLGen et EF), plutôt que de commencer avec un modèle objet comme vous le feriez avec NHibernate. Mon équipe n'arrivait pas vraiment à "comprendre" Entity Framework... il semblait plus difficile de travailler avec lui qu'avec LLBLGen.
Prenez cela avec un grain de sel ... nous avons évalué les 3 outils pendant quelques jours, donc notre expérience avec EF et NHibernate n'est pas particulièrement approfondie.
Voici la prémisse de base :
Les développeurs passent trop de temps dans la couche de données, à écrire du sql, à se soucier de la base de données, etc. Pourquoi ne pas laisser un framework s'en occuper ? Ne vous souciez pas des détails.
C'est le principe d'Entity Framework et d'autres ORM.
Certains des aspects positifs d'Entity Framework :
Modélisation Pas d'insertion fastidieuse, pas de mise à jour, moins de code à écrire. Suivi des changements d'objets Etc. (il y en a d'autres, vous pouvez aller sur le site de Micorsoft pour plus de détails)
Mais, à mon avis, les développeurs devraient se préoccuper des détails.
Après tout, vous êtes un développeur, non ? Cela est particulièrement vrai si l'application est centrée sur la base de données.
De nombreuses "activités de la boîte magique" sont réalisées avec ces cadres. Ce sont des générateurs de code. Ils génèrent beaucoup de SQL pour effectuer les insertions, les mises à jour, etc. lors de leur exécution s'ils n'utilisent pas directement les SP. Lorsque les choses vont mal (performances, mémoire, etc.), comment ouvrir la boîte magique ? Vous devez également apprendre les tenants et aboutissants du fonctionnement de la boîte magique. Parfois, elle fait des choses auxquelles vous ne vous attendez pas.
Je pense donc qu'Entity Framework est utile, mais que l'acheteur doit se méfier.
Je pense qu'il serait plus utile pour les petits projets, lorsque vous avez un modèle de données direct et que vous avez besoin de faire quelque chose rapidement et que vous n'avez pas vraiment envie de passer du temps à écrire du SQL ou à vous amuser avec le DAL.
Si vous construisez une grande application qui est le cœur de votre entreprise, je pense qu'il vaut mieux passer du temps dès le départ pour apprendre et faire tout l'accès aux données vous-même, parce que lorsqu'il y a des problèmes (et il y en aura), vous serez capable de creuser directement et de trouver la solution. De plus, la plupart des applications de base durent plusieurs années. Ce(s) cadre(s) ont probablement une durée de vie plus courte que les applications de base de votre entreprise.
Je vous suggère de jeter un coup d'oeil à http://stackoverflow.com/questions/tagged/entity-framework pour plus d'informations sur le cadre de l'entité et comment il se compare aux autres outils.
J'ai beaucoup de mal avec le nouveau Entity Framework 4. A cause d'un petit problème de concurrence. Le vrai problème avec Entity Framework est : - Pas de site web normal pour me donner des réponses ou pour poster mes problèmes. - Pas de bonne documentation pour les bonnes pratiques - Aucun tutoriel pour les bonnes bases de l'utilisation de l'entité (les CRUD à une seule dimension que tout le monde poste sur Internet sont plutôt inutiles).
Et enfin, comme la plupart des ORM : Il est difficile de le faire fonctionner comme vous le souhaitez.
Michel - quels sont précisément vos problèmes de concurrence ? Nous sommes en train d'évaluer EF pour un grand projet qui est sur le point de démarrer. Nous avons déjà utilisé des ORM sur de grands projets (LLBLGen), mais nous nous intéressons à l'ORM natif de MS via EF. Tout aperçu de vos points de douleur serait utile.
Vous pouvez trouver des informations assez détaillées ici : http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx
Pour ce qui est de la question initiale, je pense que EF vaut la peine d'être appris, car nous en entendrons probablement parler pendant des années. Même si votre équipe/entreprise ne l'utilise pas actuellement, il est probable qu'il sera présent dans nos vies à l'avenir.... donc, à mon avis, il est bon d'étudier toutes les choses nouvelles qui nous entourent.
J'ai passé environ 10 heures à l'évaluer et voici ce que j'ai trouvé :
-Quelle est votre opinion à ce sujet ? - Jusqu'à présent, la version 4 semble répondre aux caractéristiques minimales acceptables de l'ORM.
Dois-je l'apprendre ? - à mon avis oui. veuillez voir mes commentaires ci-dessus.
-Quels sont ses points forts ? - support des outils natifs dans VS
-Quels sont ses points faibles ? - Je suis d'accord avec l'autre poster que d'autres outils ORM peuvent être beaucoup plus faciles. J'utilise LLBLGen depuis environ 4 ans maintenant. Je me souviens qu'il y avait une courbe d'apprentissage rapide, mais pour une raison quelconque, cela ne semblait pas prendre beaucoup de temps du tout.
Je trouve que le manque d'inclusions fortement typées et l'aide pour la traversée des modèles dans les inclusions sont un peu faibles.
De plus, dans la version précédente, le manque de support pour les FK rendait EF inutilisable à mon avis.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.