LINQ to SQL est-il mort ou vivant?

95

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

rp.
la source
Rien dans cette annonce ne dit quoi que ce soit sur la disparition de LINQ ou LINQ to SQL ...?
Codewerks
5
@AugustLights Je pense que l'annonce dit que "nous ne supprimerons pas LINQ to SQL, mais nous allons donc l'ignorer totalement sur EF"
Jon Limjap
Jon - C'est comme ça que je l'ai lu. L'annonce disait: "... l'Entity Framework sera notre solution d'accès aux données recommandée pour LINQ aux scénarios relationnels." Cela se traduit par au revoir, LINQ to SQL.
rp.
4
MFC n'est pas mort, ce n'est tout simplement pas la solution préférée. Codez-vous toujours MFC? VB6 est toujours pris en charge, codez-vous cela? Il en a toujours été ainsi, MS fait ce qu'elle veut, pas ce que vous voulez.
gbjbaanb
1
@rp: Que vouliez-vous dire sous DOA - Dead or Aliveou Dead on arrival?
abatishchev

Réponses:

64

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

KristoferA
la source
14
Les créateurs de StackOverflow ont adopté Linq to SQL comme leur ORM de choix. Apparemment, ils ont décidé que les avantages l'emportaient sur les risques.
Robert Harvey
Est-ce toujours vrai? J'ai entendu dire que StackOverflow s'est éloigné de L2S mais je n'arrive pas à trouver ces informations.
Aaron
2
@Aaron, oui, ils utilisent du SQL écrit à la main avec leur propre micro-ORM appelé Dapper. Ils peuvent toujours utiliser LINQ-to-SQL sur les sections les moins populaires du site.
CMircea
28

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.

Bevan
la source
La syntaxe SQL LINQ 2 est suffisamment similaire à Entity Framework pour que vous puissiez vous déplacer assez facilement entre les deux.
Jason Short
Sa question est toujours d'actualité, car la mise en œuvre réelle de LINQ to SQL présente certains avantages spécifiques par rapport à SQL Server.
Tor Haugen
21

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.

Scott Barnes
la source
Lol. cela me fait craquer. avez-vous dû obtenir l'approbation de Microsoft pour faire cette déclaration publique? : p
Kolob Canyon
hein? en 2009, c'était un message que l'équipe en question a raté, alors j'ai dû le réparer ... en tant que chef de produit de .net: D
Scott Barnes
13

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 .

Amy B
la source
Wow, j'ai dû passer une journée vraiment littérale. Ce n'est qu'avec une interprétation hors contexte vraiment stricte de la phrase qui est la question - ma réponse a même un sens.
Amy B
@David B, oui ... J'étais comme, c'est une bonne réponse, je ne vois pas comment cela répond à cette question. lol
mmcdole
1
Il continue de recevoir des votes positifs. Je suppose que certaines personnes ont juste besoin de voir les informations dans les liens ... Si vous avez aimé cette réponse, vous aimerez peut-être ma meilleure réponse ici: stackoverflow.com/questions/471502/what-is-linq/471592#471592
Amy B
8

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?

Sam
la source
7

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.

Jon Limjap
la source
6

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.

Jason court
la source
1
Re .: "Vous ne pouvez pas écrire un fournisseur LINQ to SQL - il n'y a pas de modèle pour cela." Eh bien, il y en a . C'est juste qu'ils ont décidé de rendre les membres nécessaires privés de dernière minute pour donner un avantage à EF. Voir blogs.msdn.com/mattwar/archive/2007/05/31/…
KristoferA
1
Désolé, le lien précédent aurait dû être blogs.msdn.com/mattwar/archive/2008/05/04/…
KristoferA
Merci - n'avait pas lu ce message. Je savais qu'il y avait une API en interne, mais je ne savais pas si cela avait déjà été rendu public.
Jason Short
1
Le même blog ( blogs.msdn.com/mattwar ) contient également une série d'articles complets (avec des exemples) sur la façon d'écrire des fournisseurs et un fournisseur L2S téléchargeable enfichable que vous pourriez trouver utile.
KristoferA
Peu importe si vous pouvez le pirater - il n'est PAS officiellement pris en charge par MS. Vous n'avez AUCUNE intégration VSIP pour cela. Vous ne pouvez pas obtenir de logo pour votre application ...
Jason Short
5

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?

Gabriel Isenberg
la source
4

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).

MarkJ
la source
pour moi, le meilleur est pur ado.net avec OracleConnection et SqlConnection parce que ces fournisseurs et System.Data.DataSet ne meurent jamais. Est la base des données tabulaires. Personnel j'aime EF mais les DataSet professionnels continuent d'être une norme.
pedrofernandes
3

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.

Korro
la source
1
L'approche EF actuelle présente de sérieux problèmes, notamment la classe de base appliquée. Je m'attendrais à ce qu'EFvNext soit assez différent à certains endroits; jusque-là, je recommanderais d'utiliser l'option la plus simple: L2S - ou nHibernate ;-p
Marc Gravell
1
Une fois que vous avez compris LINQ, je dirais que "apprendre" LINQ to SQL est assez trivial. Il s'agit simplement d'ajouter un élément LINQ to SQL classes à votre projet et de glisser-déposer quelques tables sur le concepteur.
Richard Ev
3

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.

terjetyl
la source
2

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.

Craig
la source
2

(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.

Tor Haugen
la source
Eh bien, ils pourraient le tuer en ne l'incluant pas dans Dot Net 4 qui est censé être une installation côte à côte. Ce qui signifierait que les applications dot net 4 n'y auraient pas accès sans installer 3.5SP1 sur la même machine - je ne sais pas si c'est vrai ou non.
Jason Short
Quelqu'un se souvient de VB6? Microsoft prend toujours en charge VB6 (en quelque sorte). Ils disent toujours qu'ils écoutent les clients VB6 même maintenant. Mais sommes-nous heureux? Non. Les chemins de mise à niveau pour obtenir notre code vers la technologie de remplacement, VB.Net, sont coûteux. Alors considérez simplement cette leçon: et pensez à savoir si LinqToSQL sera dans .NET 4, 5, 6 ... et à quel point cela compte pour vous.
MarkJ