LINQ to SQL est-il mort?


17

Y a-t-il une raison de continuer à utiliser Linq en SQL, ou est-il préférable de passer aux techniques ORM comme EF, NHibernate, etc.

Nous utilisons Linq to SQL dans une nouvelle application de grande entreprise qui existera longtemps. La motivation de cette nouvelle application d'entreprise est que l'application était écrite de façon ordinaire en Visual Basic et puisque Microsoft a arrêté le support, nous avons été obligés de réécrire l'application. Il semble que nous y soyons déjà mais cette fois avec notre DAL (Data Access Layer).

J'ai déjà lu cet article , mais il ne se compare qu'à la faiblesse d'EF.


+1 grand Q. C'est fascinant pour moi, j'ai envisagé de déplacer mes procédures stockées et mes chaînes de requête SQL paramétrées vers LINQ to SQL pour une meilleure lisibilité, je n'avais aucune idée qu'il n'était plus développé.
fearoffours

MS a un petit type de diaporama .NET 4 qui dit qu'il n'est pas mort - mais cela peut signifier beaucoup de choses. Ils l'ont amélioré dans .NET 4.0: damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
MetalMikester

Pas encore. Cette question a été débattue ad-nauseum sur StackOverflow. Pouvez-vous dire FUD?
Robert Harvey

Réponses:


11

Si vous l'utilisez déjà et ne rencontrez aucune difficulté, je m'en tiendrai aux projets existants.

Linq2SQL est un ORM assez agréable, mais limité - si vous voulez mapper vos objets de manière plus complexe que celles de base fournies par Linq2SQL, alors vous allez être bloqué. Microsoft a corrigé quelques bugs lors de la sortie de .net 4, mais a déclaré qu'il ne consacrerait pas de ressources à son extension.

Je dirais que si vous avez un projet assez simple qui a peut-être une durée de vie limitée, Linq2SQL est un choix léger décent tant que vous faites attention à ne pas divulguer les dépendances à Linq2SQL partout. Pour quelque chose de plus, j'irais avec autre chose (NHibernate ou EF par exemple) car Linq2SQL est à peu près une impasse.


Je ne peux qu'être d'accord, pas vraiment mort, mais c'est sur la table dans le triage d'une manière ou d'une autre. Si les choses fonctionnent et que cela a un impact énorme de les changer maintenant ... eh bien, vous voudrez peut-être vous asseoir un peu et chercher un bon moment pour mettre la conversion en EF / NHibernate, pourrait être un projet de mise à niveau financé (à la fin, nous tous veulent un travail, du pain et du beurre sur la table).
Cyberzé

@cyberzed: Cela ressemble à une bonne excuse pour un travail inutile.
Robert Harvey

12

Ce n'est pas mort, mais Microsoft se concentre désormais sur Entity Framework.

J'ai utilisé LINQ to SQL sur de petits projets, et c'est assez agréable en tant que couche de données légère et j'envisagerais de l'utiliser à nouveau sur des projets de taille similaire. La mise en œuvre de LINQ elle-même est vraiment bonne et jusqu'à récemment bien meilleure que le projet NHibernate LINQ. Sur le plus grand projet sur lequel j'ai utilisé L2S, j'ai eu du mal à trouver un modèle d'unité de travail qui me plaisait, en raison des limitations de la classe L2S 'DataContext'. Essayer d'implémenter quelque chose comme «Session per request» avec L2S semble soit très difficile, soit impossible.

Je ne considérerais pas non plus vraiment L2S comme un véritable ORM, car il ne vous donne vraiment pas beaucoup d'options de mappage. La conception de votre classe doit vraiment suivre votre schéma de base de données (table par classe), sinon il se battra avec vous à chaque étape du processus. Une autre chose que je n'aime pas à propos de L2S est la nécessité d'utiliser des types spécifiques ( EntitySetetEntityRef ) pour gérer les collections, les références et le chargement différé. Cela signifie qu'il n'est pas possible de garder votre modèle de domaine ORM agnostique sans ajouter une autre couche d'abstraction.

Mon autre problème avec L2S est la seule dépendance à LINQ pour générer des requêtes. Le fournisseur LINQ est très bien écrit et crée généralement un SQL décent pour la majorité des requêtes, mais je crains qu'il n'y ait des requêtes plus complexes qui ne peuvent pas être bien exprimées avec LINQ. En utilisant L2S, vous devez essentiellement revenir à l'appel de procédures stockées dans ces cas, alors que (par exemple) NHibernate possède plusieurs API (fournisseur LINQ, QueryOver, HQL, etc.) qui peuvent être utilisées lorsque vous souhaitez plus de contrôle sur le SQL généré.

Dans la défense de L2S contre NHibernate, il y a beaucoup moins de frais généraux pour le faire fonctionner sur un projet.


2

Il n'est pas mort car il fonctionne toujours, mais s'il n'est pas développé davantage, il peut être judicieux de passer à autre chose.

Cependant, si cela fonctionne pour votre application, il est inutile de changer pour le plaisir de changer.


2

plus stable qu'à mon humble avis:

http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx

http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/

Ils ont déplacé leurs efforts d'amélioration vers Entity Framework où il est vraiment nécessaire pour que ce produit réussisse. N'attendez rien de nouveau, mais la compatibilité et la correction de bugs sur linq2sql pendant un certain temps.

Ce site est géré avec beaucoup de linq2sql si je ne me trompe pas.


+1 pour "stable" Meilleure façon de visualiser L2S, à mon humble avis. Stable et n'étant plus étendu / modifié.
quentin-starin

Désolé mais "rien de nouveau mais la compatibilité et la correction de bogue" signifie qu'il est confiné. C'est essentiellement une garantie que la communauté s'en éloignera, vous ne verrez pas beaucoup de nouveaux projets l'utiliser et vous ne voudrez probablement pas non plus l'utiliser dans de nouveaux projets. «Mort» ne signifie pas que cela ne fonctionne pas, cela signifie simplement qu'il y a peu d'innovation ou d'intérêt.
Jeremy

Du point de vue d'une grande entreprise, le fait que le noyau ne soit plus modifié signifie qu'il peut enfin figurer sur la liste des techniques approuvées dans de nombreux cas. Dans mon travail, nous attendons cela depuis un certain temps. EF est encore trop volatile pour se lancer et L2S va toujours attirer l'intérêt dans des situations où les frais généraux d'EF ne sont pas souhaités.
Bill

@Jeremy Les gens utilisent-ils toujours TeX?
alternative

1

C'est bizarre mais j'ai beaucoup vu ce phrasé ("LINQ2SQL est mort") et je ne sais pas d'où il vient *. C'est tout aussi mort Windows XP. Microsoft a cessé de prendre en charge et a créé quelque chose de nouveau (et à mes yeux mieux), mais les gens sont toujours libres d'utiliser XP tout comme ils sont libres d'utiliser Linq2SQL. Certes, j'utilise Linq2SQL lors de la création de modules DotNetNuke personnalisés. Cependant, avec de nouvelles fonctionnalités dans EF4 telles que le développement du code en premier ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx ), il est difficile de trouver des raisons de s'en tenir à Linq2SQL. Je ne vois pas de raison de passer par le code et de le mettre à jour, mais pour le nouveau code, je ne sais pas pourquoi vous ne voudriez pas utiliser EF4.

* En toute honnêteté, je suis très… obsédée par la sémantique! Je m'excuse si cela dérange les autres :)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.