当前位置:  开发笔记 > 编程语言 > 正文

LINQ to SQL死了还是活着?

如何解决《LINQtoSQL死了还是活着?》经验,为你挑选了8个好方法。

就在我与LINQ to SQL交朋友时,似乎MS正在从它下面拉出地毯.

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

从我的一点点研究来看,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

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



1> KristoferA..:

1)他们不能"杀死"Linq-to-SQL,因为它已经是.net框架的一部分.他们可以做的是停止向其添加功能.这并不妨碍那些已经使用L2S扩展并改进它的数千名开发人员.一些核心区域触摸起来很棘手,但它们已经很坚固,缺少的设计师功能可以很容易地用螺栓固定.

2)其中一个PDC EF会议表明他们从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杂志封面故事是一个很好的阅读主题,有一些L2S与EF比较:http://visualstudiomagazine.com/features/article.aspx?editoridid = 2583

更新2:在Redmond开发者新闻中引用Anders Hejlsberg的话说" LINQ to SQL并没有死.我可以向你保证,它没有死.没有任何东西可以消失.我们从来没有这样做过,我们永远也不会. "

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


StackOverflow的创建者将Linq to SQL作为他们选择的ORM.显然他们认为这些好处超过了危险.
@Aaron,是的,他们使用带有自己的称为Dapper的微型ORM的手写SQL。他们可能仍然在网站上不太受欢迎的部分上使用LINQ-to-SQL。

2> Bevan..:

你的问题需要解决的含糊不清.

LINQ!= LINQ to SQL

有很多LINQ技术和提供商:

Linq to SQL;

Linq to Entities;

Linq to Objects;

Linq to XML;

......而那些只是来自微软的那些.还有非MS提供商,包括NHibernate.

您链接的博客文章仅讨论Linq to SQL.

LINQ的主要优点是您可以学习和使用一种查询语法,并在多种技术中重复使用它.

鉴于此,我建议任何人认为缺乏"Linq To SQL"的未来是无关紧要的,因为您在编写LINQ查询时获得的技能将来可以转移到其他工具.



3> Scott Barnes..:

我们没有杀死LINQ to SQL.我们正在优化EF,但LINQ to SQL绝对不会被淘汰:)

- 斯科特/微软.



4> Amy B..:

您不仅应该学习Linq(System.Linq.Enumerable和System.Linq.Queryable),还需要学习.net语言的编程语言增强功能.

在C#3.0中,这些包括:

扩展方法(在第一个参数上使用this关键字的静态方法)

编译器推断类型(var)

Lambda语法(根据上下文生成匿名方法或表达式)

初始化器

属性默认实现(简写)

在这里阅读更多.


在VB 9.0中,有一些内联XML魔术和许多其他东西(许多类似于上面的C#列表).

在这里阅读更多.



5> Sam..:

老实说,我不明白你在那篇文章中读到的link2sql已经死了.

在链接到它的博客文章中说:

我们正在倾听客户关于LINQ to SQL的信息,并将继续根据我们从社区收到的反馈来改进产品.

对我来说,将来会开发和支持LINQ to SQL.我想知道为什么你认为它已经死了?



6> Jon Limjap..:

当然,我认为LINQ to SQL,LINQ to Entities和LINQ to [insert 3rd Party ORM]之间的选择提供了一个完全健康的数据访问层方法生态系统,软件开发人员可以从中选择.像NHibernate,LLBLGen甚至亚力士这样的第三方提供商(不确定他们是否会提供LINQ提供商)肯定会让竞争更好,更有趣.

话虽这么说,微软放弃LINQ to SQL将是完全令人遗憾的,特别是因为它确实有很好的追随者 - 甚至StackOverflow都建立在它上面.



7> Jason Short..:

有趣的博客文章. 以及Stackoverflow帖子的一些相关信息.

基本要点似乎是在ado.net博客上发表的评论,其中说明实体框架是获得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工具.

编辑 - 我刚刚在我的博客上写了一篇稍微详细的文章

EDIT2 - IQueryable Provider - 与LINQ to SQL提供程序不同.您可以为自己喜欢的任何内容编写自己的IQueryable Provider.您没有设计师支持或模型生成.我知道没有gui设计师模型可以用于生成LINQ to SQL模型.



8> Gabriel Isen..:

我想我真的没有看到这里的问题.从您链接的文章:

我们正在倾听客户关于LINQ to SQL的信息,并将继续根据我们从社区收到的反馈来改进产品.

我错过了什么吗?什么让人觉得LINQ to SQL在到达时已经死了?

推荐阅读
k78283381
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有