就在我与LINQ to SQL交朋友时，似乎MS正在从它下面拉出地毯。
从我的一点点研究来看，EF对简单的工作来说太过分了。但是在这个公告之后是否有继续使用LINQ to SQL的意义？
除了LINQ to SQL的未来之外，这通常不会发送错误信号吗？鉴于MS在墙上投掷比特的速度，早期使用任何新比特是否合理？ （这很好，LINQ to SQL几乎不早！）。
对于我的LINQ to SQL工作，我想我要去SubSonic了！
更新：一些新意见：
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx
答案 0 :(得分：64)
1）他们无法“杀死”Linq-to-SQL，因为它已经是.net框架的一部分。他们可以做的是停止向其添加功能。这并不妨碍那些已经使用L2S扩展并改进它的数千名开发人员。一些核心领域很难触摸，但它们已经很稳固了missing designer features can easily be bolted on。
2）其中一个PDC EF sessions表明他们从EFv1惨败中吸取了一些教训，他们现在将许多好东西从L2S复制粘贴到EF并假装它是新的EF东西。换句话说，L2S版本2刚刚被“重新标记”EF。
3）LINQ本身（语言集成查询）是切片冰淇淋以来最好的东西，它可以用于除L2S之外的许多其他东西（Linq到对象，Linq到实体，Linq到XML，Linq-到任何东西）。所以DP小组试图迫使[广大的] L2S采用者转向[不太受欢迎且目前存在缺陷]的实体框架，这是没有理由不学习Linq。
另见这个帖子（我认为这部分触发了Tim的博客文章）： http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1
更新1： Roger Jennings 2008年12月发行的Visual Studio Magazine封面故事是一篇很好的读物，有一些L2S与EF比较：http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
更新2： Anders Hejlsberg在Redmond Developer News中被引用说“ LINQ to SQL并没有死。我可以向你保证，它没有死。没有什么消失我们从未这样做过，我们永远不会这样做。“
答案 1 :(得分：28)
您的问题需要解决的含糊不清。
LINQ！= LINQ to SQL
有很多LINQ技术和提供商：
......而这些只是来自微软的那些。还有非MS提供商，包括NHibernate。
您链接的博客文章仅讨论Linq to SQL。
LINQ的关键优势在于您可以学习和使用一种查询语法，并在多种技术中重复使用它。
鉴于此，我建议任何人认为缺少“Linq To SQL”的未来是无关紧要的，因为您在编写LINQ查询时获得的技能将来可以转移到其他工具。
答案 2 :(得分：21)
我们不会杀死LINQ to SQL。我们正在针对EF进行优化，但LINQ to SQL肯定不会被淘汰掉:)）
- 斯科特/微软。
答案 3 :(得分：14)
您不仅应该学习Linq（System.Linq.Enumerable和System.Linq.Queryable），还需要学习.net语言的编程语言增强功能。
在C＃3.0中，这些包括：
了解更多here。
在VB 9.0中，有一些内联XML魔术和许多其他东西（许多类似于上面的C＃列表）。
了解更多here。
答案 4 :(得分：8)
老实说，我不明白你在那篇文章中读到的内容是link2sql已经死了。
在链接到它的博客文章中说：
我们正在倾听客户关于LINQ to SQL的信息，并将继续根据我们从社区收到的反馈来改进产品。
对我而言，将来会开发和支持LINQ to SQL。我想知道为什么你认为它已经死了？
答案 5 :(得分：7)
当然，我认为LINQ to SQL，LINQ to Entities和LINQ to [insert 3rd Party ORM]之间的选择提供了一个完全健康的数据访问层方法生态系统，软件开发人员可以从中选择。像NHibernate，LLBLGen甚至亚力士这样的第三方提供商（不确定他们是否会提供LINQ提供商）肯定会让竞争更好，更有趣。
话虽如此，微软放弃LINQ to SQL将会感到非常难过，特别是因为它确实有很好的追随者 - 甚至StackOverflow都建立在它上面。
答案 6 :(得分：6)
Interesting blog post about it.以及Stackoverflow posts上的一些相关信息。
基本要点似乎是在ado.net blog上发表的评论，表明实体框架是获得Visual Studio 2010和Dot Net 4主要开发人员时间的唯一方法。
我的回答是 - DUH。我们都知道这一点。微软在PDC 2007上公开表示，LINQ to SQL是SQL Server的短期版本，因为SQL Server没有其他LINQ故事。它仅适用于SQL Server。你不能编写一个LINQ to SQL提供程序 - 它没有模型。这是一种一次性技术，不可扩展。
实体框架是Microsoft建立LINQ提供商的唯一途径。实体框架已经证明是非常具有相应性，但我认为部分原因在于LINQ to SQL今天拥有更好的程序员体验。实体框架将捕获并超越LINQ to SQL，因为它是Microsoft未来的ORM / Mapping工具。
编辑 - 我刚刚在my blog
上对此进行了更详细的描述EDIT2 - IQueryable Provider - 与LINQ to SQL提供程序不同。您可以为自己喜欢的任何内容编写自己的IQueryable Provider。您没有设计师支持或模型生成。我知道没有gui设计师模型可以用于生成LINQ to SQL模型。
答案 7 :(得分：5)
我想我真的没有看到这里的问题。从您链接的文章：
我们正在倾听客户的意见 关于LINQ to SQL和意志 继续发展基于产品 我们收到的反馈意见 社区也是如此。
我错过了什么吗？是什么让人觉得LINQ to SQL在到达时死了？
答案 8 :(得分：4)
Scott Guthrie告诉我他们不会杀死LINQ to SQL：
答案 9 :(得分：4)
有人记得VB6吗？无论你是个人厌恶还是喜欢它，微软都销售了数百万份拷贝，企业花费了数百万美元来编写数百万行VB6。接下来发生了什么？
所以请考虑这一课。对我来说，LinqToSQL支持似乎相当勉强。它们是obliged来支持它，因为它在当前的.NET框架中。但它会在.NET 5,6,7 ......吗？试想一下对你来说有多重要（据我所知，对你来说根本不重要）。
答案 10 :(得分：3)
也许你不应该费心去学习Linq to SQL，但是他们仍然会保留实体Linq。
答案 11 :(得分：3)
答案 12 :(得分：3)
很明显，在微软的工具箱中，2个ORM是一对多的，但对我来说，似乎错误的框架已被选中用于所有错误的原因。事实上，C＃团队在很短的时间内完成了ADO.NET团队应该做的工作并且更好地完成了工作，这对ado.net团队来说很难实现。并不是说我知道2个框架的内部工作原理，但我认为将linq2sql的缺点升级到实体框架要快得多。
似乎涉及太多的政治，我认为这真的会损害asp.net的声誉，因为我不相信Entity框架会给我们一个与Linq2sql同样用户友好的体验。 ado.net团队还可以从asp.net mvc团队学习一些沟通技巧，因为对问题的澄清最多是模糊的。
学习Scott Gu和他的MVC团队在这里会很有趣，因为他们的大多数例子都使用Linq2Sql。
答案 13 :(得分：2)
答案 14 :(得分：2)
（不，StingyJack，LINQ to SQL不使用实体框架）
无论如何，我不担心。 Tim说他们正在听客户关于LINQ to SQL的问题。从我见过的L2S热情来看，客户（就是我们）会说出自己的想法。
而且，正如KristoferA指出的那样，他们实际上无法“杀死”L2S，只能冻结它。 L2S一旦抛光，实际上并不需要进一步的开发。有了L2S提供程序，LINQ中的所有进展也应该在L2S中可用。所以选择仍然是我们的。
答案 15 :(得分：0)
下一版本的Windows Phone 7，代号为Mango，包含一个可通过Linq to SQL访问的SQL Server Compact Edition http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/