Pourquoi tous les Linq To Entities détestent-ils ?[fermé]

Question

J'ai remarqué qu'il semble y avoir un peu d'hostilité envers Linq To Entities, en particulier de la part des gens d'Alt.Net.Je comprends la résistance à une programmation plus "glisser-déposer", mais d'après ma compréhension, Linq To Entities ne l'exige pas.

Nous utilisons actuellement Linq to SQL, et nous utilisons le document DBML pour le définir (une fois que vous obtenez plus d'une douzaine de tables, le concepteur est plutôt inutile.)

Alors pourquoi la même approche ne fonctionnerait-elle pas pour Linq To Entities ?

Answer 1

Je ne pense pas que ce soit une haine pour le idée de celui-ci en soi.C'est juste que les gens n'aiment pas mise en œuvre de celui-ci.

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Answer 2

En fait, une fois que vous commencez à vous y plonger, le LTE est complètement inutile pour les frameworks au niveau de l’entreprise.Le fait qu'il y ait très peu de prise en charge de l'héritage (dans LTS également) entraîne beaucoup de code redondant.De plus, je reviendrai à LTS (Linq to SQL) car il vous permet en fait de définir des mappages via des attributs au lieu d'un fichier.LTE ne fonctionne qu'avec un fichier externe.

Answer 3

La haine de Linq to Entity est bien méritée.Ce produit échoue à tout objectif plus complexe que les démos boiteuses pour lesquelles GU l'utilise sur son blog.EF est loin d’être prêt pour le prime time.Microsoft ne parvient tout simplement pas à obtenir des données correctes dans le monde .BLOAT, ils semblent changer de paradigme de données à chaque fois que le vent souffle.FoxPro existe depuis 20 ans avec le même noyau de données de base.Étant donné que SQL Server utilise une grande partie de la technologie de données VFP, MSFT pourrait peut-être en apprendre un peu plus sur la manipulation des données et les langages centrés sur les données à partir de quelque chose qui a fonctionné.

Answer 4

Je suis assez convaincu des principes de Linq to Entities et d'Entity Framework en général, mais j'ai des réserves quant à son incarnation actuelle.J'admets cependant librement ne pas l'avoir utilisé autrement que de manière auto-éducative et très modeste.Le niveau de flexibilité ne semble pas encore atteint, mais je suis sûr qu'il viendra.L'un des évangélistes de la technologie MS (excellent titre de poste) m'a dit qu'EF était le choix stratégique MS pour l'avenir.En supposant que ce soit le cas, je ne peux que voir les choses s’améliorer dans ce domaine.

Answer 5

Il pourrait également y avoir un peu d'animosité liée à la « seconde place ».La SEP est très tardivement sur le marché avec L2E, je me suis moi-même intéressé à ORM il y a environ trois ans et MS n'était plus visible à ce stade.

Beaucoup d'entre nous ont déjà passé du temps à apprendre un autre ORM (tel que NHibernate) et sont habitués à un certain niveau et type de fonctionnalités disponibles et cela n'est pas encore évident dans L2E.

Cette animosité de "seconde place" n'est pas une vieille nouvelle pour être honnête. Je ne sais pas pourquoi MS ne passe pas plus de temps à prendre en charge les solutions déjà en place, nous avons déjà vu cela avec NAnt -> MSBuild et NUnit -> MsTest. , cela permettrait à chacun d'économiser beaucoup de temps et d'efforts s'il acceptait simplement l'une des solutions les meilleures et les plus matures et s'efforçait de la soutenir au lieu de brasser la sienne tout le temps.

Answer 6

J'ajouterais que la mise en œuvre LTE de l'héritage TPT est tout simplement criminelle.Voir ma question ici.

Et pendant que j'y suis, je crois que les nombreux experts EF publiés sont au moins en partie complices.Je n'ai pas encore trouvé de documents publiés sur EF mettant en garde contre les requêtes de types de base.Si je devais l'essayer sur le modèle que j'ai, SQL Server abandonne simplement à l'exception.

Une partie de votre déclaration SQL est imbriquée trop profondément.Réécrivez la requête ou divisez-la en requêtes plus petites.

J'adorerais réécrire la requête, mais LTE m'a libéré de ce fardeau.Merci (^non)