LINQ to SQL est-il mort ou vivant?

Juste au moment où je me lie d'amitié avec LINQ to SQL, il semble que MS retire le tapis de dessous.

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

D'après mes quelques recherches, EF est bien exagéré pour un travail simple. Mais après cette annonce, est-il utile de continuer à utiliser LINQ to SQL?

Au-delà de l'avenir de LINQ to SQL, cela n'envoie-t-il pas généralement un mauvais signal? Étant donné la vitesse à laquelle MS lance des bits contre le mur, est-il rationnel d'utiliser l'un des nouveaux bits tôt? (et c'est gentil, il n'est guère tôt pour LINQ to SQL!).

Pour mon travail LINQ to SQL, je pense que je me dirige vers SubSonic!

Mise à jour: Quelques nouvelles opinions:

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1) Ils ne peuvent pas "tuer" Linq-to-SQL car il fait déjà partie du framework .net. Ce qu'ils peuvent faire, c'est arrêter d'y ajouter des fonctionnalités. Cela n'empêche pas les milliers de développeurs qui utilisent déjà L2S de l'étendre et de l'améliorer. Certaines zones centrales sont difficiles à toucher, mais elles sont déjà solides et les fonctionnalités manquantes du concepteur peuvent facilement être boulonnées .

2) L'une des sessions PDC EF montre qu'ils ont appris quelques leçons du fiasco EFv1 et qu'ils copient et collent maintenant beaucoup de goodies de L2S dans EF et prétendent que c'est de nouveaux trucs EF. En d'autres termes, la deuxième version de L2S vient d'être "ré-étiquetée" EF.

3) LINQ en tant que tel (Language Integrated Query) est la meilleure chose depuis la glace en tranches et il peut être utilisé avec beaucoup d'autres choses que L2S (Linq aux objets, Linq aux entités, Linq à XML, Linq-à-tout ). Ainsi, la tentative du groupe DP de forcer [les vastes masses] d'adopteurs de L2S à [le moins populaire et actuellement imparfait] Entity Framework n'est pas une raison pour ne pas apprendre Linq.

Voir également ce fil de discussion (qui, selon moi, a en partie déclenché le billet de blog de Tim): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

Mise à jour 1: Le numéro de décembre 2008 de l'article de couverture de Visual Studio Magazine par Roger Jennings est une bonne lecture sur le sujet, avec quelques comparaisons L2S vs EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Mise à jour 2: Anders Hejlsberg a été cité dans Redmond Developer News comme disant " LINQ to SQL n'est pas mort. Je peux vous assurer que ce n'est pas mort. Rien ne disparaît jamais. Nous n'avons jamais fait cela et nous ne le ferons jamais. "

http://reddevnews.com/blogs/weblog.aspx?blog=3016

Il y a une ambiguïté dans votre question qui doit être résolue.

LINQ! = LINQ vers SQL

Il existe tout un tas de technologies et de fournisseurs LINQ:

• Linq vers SQL;
• Linq aux entités;
• Linq aux objets;
• Linq vers XML;

... et ce ne sont que ceux de Microsoft. Il existe également des fournisseurs non-MS, y compris NHibernate.

Le billet de blog que vous avez lié ne parle que de Linq to SQL.

Le principal avantage de LINQ est que vous pouvez apprendre et utiliser une seule syntaxe de requête et la réutiliser dans plusieurs technologies.

Compte tenu de cela, je suggérerais que tout manque d'avenir perçu pour "Linq To SQL" n'est pas pertinent, car les compétences que vous acquérez en écrivant des requêtes LINQ seront transférables à d'autres outils à l'avenir.

Nous ne tuons pas LINQ to SQL. Nous optimisons pour EF, mais LINQ to SQL n'est certainement pas en train d'être tué :)

- Scott / Microsoft.

Non seulement vous devriez apprendre Linq (System.Linq.Enumerable et System.Linq.Queryable), mais vous devrez également apprendre les améliorations du langage de programmation pour votre langage .net.

En C # 3.0, ils incluent:

• Méthodes d'extension (méthodes statiques avec le mot clé this sur le premier paramètre)
• Types inférés du compilateur (var)
• Syntaxe Lambda (qui génère une méthode anonyme ou une expression selon le contexte)
• Initialiseurs
• Implémentation par défaut de la propriété (un raccourci)

En savoir plus ici .

Dans VB 9.0, il y a de la magie XML en ligne, et bien d'autres choses (beaucoup sont similaires à la liste ci-dessus pour C #).

En savoir plus ici .

Honnêtement, je ne comprends pas où dans cet article vous lisez que link2sql est mort.

Dans l'article de blog que vous avez lié, il est dit:

Nous sommes à l'écoute des clients concernant LINQ to SQL et continuerons à faire évoluer le produit en fonction des commentaires que nous recevons de la communauté.

Pour moi, cela se lit comme LINQ to SQL sera développé et pris en charge à l'avenir. Je me demande pourquoi tu penses qu'il est mort?

Certes, je pense que le choix entre LINQ to SQL, LINQ to Entities et LINQ to [insérer un ORM tiers] ici fournit un écosystème parfaitement sain de méthodologies de couche d'accès aux données parmi lesquelles un développeur de logiciel peut choisir. Les fournisseurs tiers comme NHibernate, LLBLGen et même Subsonic (je ne sais pas s'ils vont proposer des fournisseurs LINQ) rendront certainement la concurrence meilleure et plus intéressante.

Cela étant dit, il sera totalement triste pour Microsoft d'abandonner LINQ au profit de SQL, d'autant plus qu'il a un bon suivi - même StackOverflow est construit dessus.

Article de blog intéressant à ce sujet. Et quelques informations connexes sur les publications Stackoverflow .

L'essentiel semble être des commentaires faits sur le blog ado.net qui déclarent que Entity Framework est la seule chose qui donne du temps aux développeurs majeurs pour Visual Studio 2010 et Dot Net 4.

Ma réponse est - DUH. Nous savons tous cela. Microsoft a déclaré publiquement lors du PDC 2007 que LINQ to SQL était une version à court terme pour SQL Server car il n'y avait pas d'autre histoire LINQ sur SQL Server. Cela ne fonctionne qu'avec SQL Server. Vous ne pouvez pas écrire un fournisseur LINQ to SQL - il n'y a pas de modèle pour cela. C'était une technologie unique, non extensible.

L'Entity Framework est le SEUL moyen de Microsoft pour créer un fournisseur LINQ. L'Entity Framework s'est avéré assez contreversial, mais je pense que cela est en partie dû au fait que LINQ to SQL a une meilleure expérience de programmeur aujourd'hui. Entity Framework capturera et surpassera LINQ to SQL car il s'agit de l'outil ORM / Mapping du futur de Microsoft.

EDIT - Je viens de faire un article un peu plus détaillé à ce sujet sur mon blog

EDIT2 - IQueryable Provider - n'est PAS la même chose qu'un fournisseur LINQ to SQL. Vous pouvez écrire votre propre fournisseur IQueryable pour tout ce que vous voulez. Vous n'obtenez aucun support de concepteur ou génération de modèle. À ma connaissance, il n'existe aucun modèle de concepteur d'interface graphique permettant de se connecter à la génération de modèles LINQ to SQL.

Je suppose que je ne vois pas vraiment le problème ici. De l'article que vous avez lié:

Nous sommes à l'écoute des clients concernant LINQ to SQL et continuerons à faire évoluer le produit en fonction des commentaires que nous recevons de la communauté.

Est-ce que je manque quelque chose? Qu'est-ce qui donne l'impression que LINQ to SQL est mort à l'arrivée?

Scott Guthrie m'a dit qu'ils ne tueraient pas LINQ to SQL:

Publier sur LINQDev.com

Quelqu'un se souvient de VB6? Que vous le détestiez ou que vous l'aimiez personnellement, Microsoft a vendu des millions d'exemplaires et les entreprises ont dépensé des millions de dollars pour écrire des millions de lignes de VB6. Que s'est-il passé ensuite?

• Eh bien, Microsoft prend toujours en charge VB6 (en quelque sorte - pas l'EDI).
• Et Microsoft dit toujours qu'ils écoutent les clients VB6 même maintenant ( en septembre 09 ).
• Mais les clients VB6 sont-ils satisfaits? Pas depuis 2002 , 4 ans après le lancement de VB6.
• Pourquoi pas? Les chemins de mise à niveau de votre investissement de code vers la technologie de remplacement, VB.Net, sont coûteux .

Alors considérez simplement cette leçon. Pour moi, il semble que le support LinqToSQL sera plutôt réticent. Ils sont obligés de le supporter car il se trouve dans le framework .NET actuel. Mais sera-ce dans .NET 5, 6, 7 ...? Pensez simplement à combien cela compte pour vous (pour autant que je sache, cela ne compte pas du tout pour vous).

Peut-être que vous ne devriez pas prendre la peine d'apprendre Linq to SQL, mais il y a toujours les entités Linq qu'ils conserveront.

Voir aussi http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx et les commentaires y

Il est évident que 2 ORM sont un à plusieurs dans la boîte à outils de Microsoft, mais il me semble que le mauvais cadre a été choisi pour toutes les mauvaises raisons. Le fait que l'équipe C # ait fait le travail que l'équipe ADO.NET était censée faire en un temps beaucoup plus court et a fait le travail bien mieux est difficile à avaler pour l'équipe ado.net. Non pas que je connaisse le fonctionnement interne des 2 frameworks mais je pense qu'il serait beaucoup plus rapide de mettre à niveau les lacunes de linq2sql vers le framework d'entité.

Il semble y avoir trop de politique impliquée et je pense que cela va vraiment nuire à la réputation d'asp.net, car je n'ai aucune confiance dans ce cadre Entity qui nous donnera une expérience tout aussi conviviale que Linq2sql. L'équipe ado.net pourrait également acquérir des compétences en communication de l'équipe asp.net mvc car les clarifications sur le problème sont au mieux vagues.

Ce serait amusant d'apprendre ce que Scott Gu et son équipe MVC représentent ici car la plupart de leurs exemples utilisent Linq2Sql.

C'était toujours un peu étrange qu'avec Linq 2 Sql et Entity Framework, il y ait de grandes zones de chevauchement. Je pense que la seule raison pour laquelle L2S n'est jamais entré dans la version .NET 3.5 était parce qu'il y avait un grand doute qu'EF verrait jamais le jour. Maintenant que EF1 est sorti, que ce soit une v1 très rude, il n'y avait plus besoin de L2S.

(non, StingyJack, LINQ to SQL n'utilise pas le framework d'entité)

Quoi qu'il en soit, je ne m'inquiéterais pas. Tim déclare qu'ils écoutent les clients concernant LINQ to SQL. À en juger par l'enthousiasme que j'ai vu pour L2S, les clients (c'est nous) s'exprimeront.

Et, comme le souligne KristoferA, ils ne peuvent pas réellement «tuer» L2S, mais seulement le geler. Et L2S, une fois poli, ne nécessite pas vraiment de développement supplémentaire. Avec le fournisseur L2S en place, toutes les avancées de LINQ devraient également être disponibles dans L2S. Le choix sera donc toujours le nôtre.

La prochaine version de Windows Phone 7, nom de code Mango, comprend une édition SQL Server Compact accessible via Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/