Pensez-vous qu'il est avantageux de passer à Entity Framework?

Question

Étant donné que LINQ to SQL n'obtiendra probablement pas autant de développement actif que Entity Framework, pensez-vous qu'il est préférable de passer à Entity Framework?

J'ai personnellement trouvé que EF était très maladroit et difficile à utiliser par rapport à LINQ to SQL, ce qui me semble très naturel.

EDIT: J'ai récemment publié un article sur mon blog au sujet de mes sentiments à l'égard de cette décision potentiel ...

ADO.NET v LINQ to SQL

Answer 1

OMI, au moment.

Il est clair (à partir de recent announcements en particulier) que EF est en pour de lourdes révisions que le scénario "thunderdome" se joue entre LINQ-to-SQL et EF. Quoi qu'il arrive, EF (dans quelques années) sera certainement très différent de EF aujourd'hui. Ou certainement "assez différent" ;-p

En tant que tel, mon avis est: coller avec simple. Et simple est LINQ-to-SQL.

Je ne vois pas beaucoup d'avantages à apprendre un système notoirement complexe si je sais que ça va changer très bientôt.

Et je suis 100% avec vous sur LINQ to SQL ;-P

Si je besoin de quelque chose de plus que LINQ to SQL en ce moment, je regarderais NHibernate ou LLBLGen Pro peut-être.

(modifier - comme une mise à jour, ma position a adouci un peu, et herehere - mais je suis toujours en utilisant LINQ to SQL comme mon principal outil, aussi - LINQ to SQL isn't quite dead yet; -p).

Answer 2

Plusieurs développeurs expérimentés ont donné "ADO .NET Entity Framework Vote of No Confidence" comme on le verra plus loin here.

Je pense que nous nous attendons à ce qu'il soit amélioré de manière significative en .Net 4.0 par l'équipe ADO.Net.

Et voici quelques video du récent PDC.

Answer 3

Pour mémoire, une certaine hésitation quant à l'avenir de LINQ to SQL a été exprimé ici:

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

Answer 4

Je suis d'accord avec Marc Gravell. Peut-être que lors de la sortie de la prochaine version d'Entity Framework (.net 4.0/VS2010), il y aura un avantage à utiliser EF, et il sera probablement très différent de la version actuelle de EF. Jusque-là au moins j'éviterai EF comme la peste pour autre chose que des tests/codes expérimentaux qui ne frapperont jamais la production.Le EF msdn forumEF msdn forum est plein d'exemples pourquoi EF n'est pas prêt pour le prime-time, mais je suis one particular example qui est un gagnant clair - ce qui serait normalement une simple requête de cinq tables (10-15 lignes de SQL) devient >1500 lines of SQL lorsque vous utilisez EF et le contrôle EntityDataSource:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1

http://paste-it.net/public/q6ed5c2/

et quant à l'avenir de EF - avec Microsoft history of changing direction sur de grandes choses stratégiques durant la nuit, qui sait si leur s actuel » objectif trategic "avec EF se réalisera dans quelques années à partir de maintenant ..? Je suis sûr que je ne parierais pas dessus. Voir:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623

Answer 5

LINQ to SQL ne semble pas être une option sauf si vous utilisez SQL Server (ou SQL Server Compact), de sorte que moi était une raison suffisante pour l'éviter et utiliser EF (je voulais utiliser PostgreSQL).

Il y a certainement assez de choses manquantes dans v1 de EF qui me ferait hésiter à le recommander. Il semble que la version 2 de l'EF (une fois sortie) soit la première version qui pourrait être sérieusement recommandée pour passer à.

Answer 6

Si vous faites du développement piloté par base de données, EF a de réels avantages aujourd'hui. J'ai utilisé à la fois LINQ to SQL et EF et travaillé à travers les nombreuses petites frustrations de EF v1.

Cependant, la seule chose qui a fait gagner EF v1 pour moi est la mise à jour étonnamment bonne de la base de données. Incroyablement, ce fonctionne réellement! Cela peut sembler trivial, mais si vous faites un design basé sur la base de données, vous voulez vous appuyer sur des outils pour créer vos classes pour vous et vous ne voulez pas avoir à régénérer votre modèle entier juste pour faire un changement.

Cela seul rend EF v1 mon choix. Je suggère d'ignorer les fonctionnalités avancées de EF v1 - il est loin d'être encore utilisable comme la plate-forme ambitieuse qu'il vise à être.

Mettez-vous à l'aise avec EF v1 et vous serez dans la meilleure position pour l'avenir.

Pete.

Answer 7

J'ai terminé quelques projets MVC actuellement en production avec L2SQL sous le capot et j'ai trouvé cela très agréable à utiliser. Je suis en train de me lancer dans un nouveau projet et j'ai décidé de l'écrire en utilisant EF et L2EF étant donné les articles précédemment cités proclamant la mort de L2SQL. Après seulement quelques jours, j'ai décidé de retourner à L2SQL. Des choses simples comme avoir à mettre des clés étrangères pour les insertions en utilisant soit la syntaxe terrible ci-dessous ou des recherches inutiles m'ont choqué.

foo.Foreign_TypeReference.EntityKey = 
    new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId); 

Plutôt que:

foo.Foreign_Type_Id = ForeignTypeId; 

Je ne pense pas que ce sera si difficile au port L2SQL à une future version de EF comme L2SQL a un sous-ensemble de la fonctionnalité (bien mieux mis en œuvre). Les quelques choses que L2EF n'a pas L2EF, par exemple Single() et SingleOrDefault(), peuvent être migrées vers EF en créant quelques méthodes d'extension. Je pense qu'il faudra beaucoup moins de temps pour faire fonctionner le système en utilisant L2SQL et ensuite le porter plus tard quand EF n'est pas si malodorant.

Answer 8

Récemment, j'ai dû rechercher quel projet ORM utiliser. Au début - essayé L2S. Ce n'était pas mal du tout, mais c'est déjà obsolète (MS ne le supportera plus), c'est pourquoi j'ai commencé à vérifier L2E. Je suis bien avec le code généré, mais la création de fausses vues, les entités et les mappages entre eux juste pour rendre la procédure stockée disponible pour ne pas remplir tous les champs de l'entité était une exagération pour moi. Et je voulais séparer ma couche dataaccess, donc - je devais mapper les données des objets générés à celles que j'avais faites.

Il m'a fallu quelques heures d'expérimentation avec NHibernate + Fluent NHibernate + LINQ pour NHibernate
pour coller avec cette combinaison.