Juste quand je me lie avec LINQ to SQL, il semble que MS tire le tapis de dessous.
D'après mes recherches, EF est un peu trop pour un travail simple. Mais après cette annonce, y a-t-il lieu de continuer à utiliser LINQ to SQL?
Au-delà de l’avenir de LINQ to SQL, cela n’envoie-t-il pas simplement un mauvais signal? Compte tenu de la rapidité avec laquelle les États-Unis lancent des bits contre le mur, est-il rationnel d'utiliser l'un des nouveaux bits à un stade précoce? (et c’est gentil, c’est à peine si LINQ to SQL!).
Pour mon travail LINQ to SQL, je pense que je me dirige vers SubSonic!
Mise à jour: Quelques nouveaux avis:
http://ayende.com/Blog/archive/2008/10/31/Microsoft-kills-linq-to-sql.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 d’arrêter d’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 délicates à toucher, mais elles sont déjà solides et/ les fonctionnalités manquantes du concepteur peuvent facilement être intégrées .
2) L’une des PDC sessions EF montre qu’elles ont tiré quelques leçons du fiasco de EFv1 et qu’elles copient et copient bon nombre des bonus de L2S dans EF et qu’ils le prétendent est nouveau truc EF. En d'autres termes, la version 2 de L2S vient d'être "ré-étiquetée" EF.
3) LINQ en tant que tel (Langage Intégré) est la meilleure chose depuis la glace en tranches et il peut être utilisé avec beaucoup d'autres choses que L2S (Linq vers objets, Linq vers entités, Linq vers XML, Linq vers n'importe quoi ). Ainsi, la tentative du groupe des PDD de forcer [la grande masse] d'adoptants de L2S à [Entity Framework [le moins populaire et le plus imparfait actuellement] n'est pas une raison pour ne pas apprendre Linq.
Voir également ce fil (qui, à mon avis, 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 la couverture de Visual Studio Magazine par Roger Jennings est une bonne lecture du 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 fait cela et nous ne le ferons jamais. "
Votre question doit être résolue de manière ambiguë.
LINQ! = LINQ to SQL
Il existe toute une gamme de technologies et de fournisseurs LINQ:
... et ce ne sont que ceux de Microsoft. Il existe également des fournisseurs autres que ceux de la SEP, y compris NHibernate.
Le blog que vous avez lié ne parle que de Linq à SQL.
Le principal avantage de LINQ est que vous pouvez apprendre et utiliser une seule syntaxe de requête et la réutiliser entre plusieurs technologies.
Cela étant dit, je dirais que toute absence d'avenir perçue pour "Linq To SQL" est sans importance, car les compétences que vous acquérez en écrivant des requêtes LINQ seront transférables à d'autres outils à l'avenir.
Nous ne détruisons 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 devriez-vous apprendre Linq (System.Linq.Enumerable et System.Linq.Queryable), vous devrez aussi apprendre les améliorations du langage de programmation pour votre langage .net.
En C # 3.0, ils incluent:
Lire plus ici .
Dans VB 9.0, il y a de la magie XML intégrée et bien d'autres choses (beaucoup sont similaires à la liste ci-dessus pour C #).
Lire plus ici .
Honnêtement, je ne comprends pas où, dans cet article, vous avez lu que link2sql était mort.
Dans le blog que vous avez lié, il est écrit:
Nous écoutons les clients au sujet de LINQ to SQL et continuerons à faire évoluer le produit en fonction des commentaires reçus 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 que c'est mort?
Certes, je pense que le choix entre LINQ to SQL, LINQ vers Entities et LINQ to [insérer un tiers ORM] fournit ici un éco-système parfaitement sain de méthodologies de couche d'accès aux données parmi lesquelles un développeur de logiciel peut choisir. Des fournisseurs tiers tels que NHibernate, LLBLGen et même Subsonic (ne sont pas sûrs d’offrir des fournisseurs LINQ) vont certainement rendre la concurrence meilleure et plus intéressante.
Cela étant dit, il sera totalement triste pour Microsoft d’abandonner LINQ vers SQL, d’autant plus qu’il a de bonnes bases - même StackOverflow est construit sur ce logiciel.
Blog intéressant à ce sujet. Et quelques informations connexes sur Stackoverflow posts .
Le Gist de base semble être des commentaires formulés sur le blog ado.net qui indiquent qu'Entity Framework est la seule chose qui permet aux développeurs de perdre beaucoup de temps pour Visual Studio 2010 et Dot Net 4.
Ma réponse est - DUH. Nous avons tous connu cela. Microsoft a déclaré publiquement au PDC 2007 que LINQ to SQL était une version à court terme pour SQL Server car il n'y avait pas d'autre récit LINQ pour SQL Server. Cela ne fonctionne qu'avec SQL Server. Vous ne pouvez pas écrire un fournisseur LINQ to SQL - il n’existe pas de modèle pour cela. C'était une technologie unique, non extensible.
Entity Framework est le SEUL moyen de Microsoft de créer un fournisseur LINQ. Entity Framework s’est avéré assez contraire à la réalité, mais je pense que cela est dû en partie au fait que LINQ to SQL a une meilleure expérience de programmation aujourd’hui. Entity Framework capturera et dépassera 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 - Fournisseur IQueryable - 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 relier LINQ à la génération de modèles SQL.
Je suppose que je ne vois pas vraiment le problème ici. De l'article que vous avez lié:
Nous écoutons les clients en ce qui concerne LINQ to SQL et sera continuer à faire évoluer le produit en fonction sur les commentaires que nous recevons du communauté aussi.
Est-ce que je manque quelque chose? Qu'est-ce qui donne l'impression que LINQ to SQL est mort à l'arrivée?
Quelqu'un se souvient de VB6? Que vous l'aimiez ou que vous l'aimiez personnellement, Microsoft s'est 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?
Alors, considérez cette leçon. Pour moi, il semble que le support de LinqToSQL sera plutôt contrariant. Ils sont obligés de le prendre en charge car il se trouve dans le framework .NET actuel. Mais sera-ce dans .NET 5, 6, 7 ...? Pensez simplement à tout ce qui compte pour vous (pour autant que je sache, cela ne vous regarde pas du tout).
Scott Guthrie m'a dit qu'ils ne tueraient pas LINQ to SQL:
Vous ne devriez peut-être pas vous préoccuper de l'apprentissage de Linq en SQL, mais il reste encore 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 figurant.
Il est évident que 2 ORM est un pour plusieurs dans la boîte à outils de Microsoft, mais pour moi, il semble que le mauvais framework ait é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 accomplir beaucoup plus rapidement est bien 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 insuffisances 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, étant donné que je ne fais pas confiance à ce framework Entity qui nous donnera une expérience aussi conviviale que Linq2sql. L'équipe ado.net pourrait également acquérir des compétences en communication grâce à l'équipe asp.net mvc, car les éclaircissements apportés au problème sont, au mieux, vagues.
Il serait amusant d’apprendre ce que Scott Gu et son équipe MVC ont à dire ici, la plupart de leurs exemples utilisant Linq2Sql.
Il était toujours un peu étrange de constater que, avec Linq 2 Sql et Entity Framework, il y avait de grandes zones de chevauchement. Je pense que la seule raison pour laquelle L2S n’a jamais été intégrée à la version .NET 3.5 est qu’il existait un fort doute sur le fait que EF verrait le jour. Maintenant que EF1 est sorti, que ce soit une version 1 très approximative, il n’était plus nécessaire de L2S.
(Non, StingyJack, LINQ to SQL n'utilise pas le framework d'entité)
En tout cas, 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 constaté pour L2S, les clients (c'est-à-dire nous) diront ce qu'ils pensent.
Et, comme le fait remarquer KristoferA, ils ne peuvent pas réellement "tuer" L2S, mais simplement le geler. Et L2S, une fois poli, ne nécessite pas beaucoup de développement. Avec le fournisseur L2S en place, toute avancée dans LINQ devrait également être disponible dans L2S. Donc, le choix sera toujours le nôtre.
La prochaine version de Windows Phone 7, nom de code Mango, inclut un serveur SQL Server Compact Edition accessible via Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/