不得不为LINQ说几句话，驳“LINQ已死”论

起因

近日不断看到有关“LINQ已死”，“LINQ玩完了吧”的言论，甚至于更有牛人说出“程序开发最终会回到本机代码上”，暂不说这些言论是否正确，且先来看看各位的惊人言论，下面仅摘录部分：

言论1

我看园子里还有蛮多人学习和用Linq to SQL 还写了一系列文章
哎~~ 程序员的悲哀呢
被他们牵着鼻子走

言论2

玩LINQ的人傻了吧

言论3

又是一次证明跟着微软是浪费青春的,小心C#喔,各位,
我发现程序开发最终会回到本机代码上来,而不是托管的

言论4

Linq 是 Anders 最失败的一个作品， 看来当年的牛人真的老了。
linq将程序的复杂性提高了一个数量级，强迫程序员在两个语法体系间跳跃，却本质性提高开发效率
linq is dead!

言论5

废弃了好 这样的垃圾不该存活，搞得程序员劳命伤财的学习！
垃圾啊！
幸亏我拒绝LINQ

以上言论，我仅摘取了部分，其实通过这些，我只想说几个问题：

请认清事实真相

首先根本没有“LINQ已死”的说法，也没有“LINQ to SQL已死”的说法，关于“LINQ已死”的言论完全来自于社区，而起因则是ADO.NET团队的一篇《Update on LINQ to SQL and LINQ to Entities Roadmap》，文章最后说到

作为.NET 4.0的一部分，实体框架是我们推荐的在关系场景中针对LINQ的数据访问解决方案，我们聆听了客户关于LINQ to SQL的反馈，并将整合在社区收到的反馈，继续开发和改善该产品。

于是社区中就猜测微软将会放弃LINQ to SQL，请注意，ADO.NET团队只是说推荐使用ADO.NET Entity Framework，将会加大对它的投入，而并没有没有什么“废弃”言论，“已死”更无从谈起！退一步讲，就算微软不再开发LINQ to SQL，这跟LINQ又有何关系呢？LINQ to SQL只是LINQ家族中众多Providers中的一个而已，没了LINQ to SQL，不是还有LINQ to Object、LINQ to XML、LINQ to Entities的吗？况且LINQ to SQL还没死，它也不会死，作为一个轻量级的ORM框架，LINQ to SQL在中小项目以及快速开发中的优势还是非常明显的，这一点，如果你没有用过LINQ to SQL，就不要再说它是多么多么的垃圾！

投入小不等于放弃，就算微软不再开发LINQ to SQL，LINQ to SQL现在的功能已经能够大部分开发的需要，再加上它灵活的可扩展性，完全可以通过自定义一些扩展来满足自己开发的需要。

再强调一遍：请停止“LINQ已死”或者“LINQ to SQL已死”的荒谬言论吧！

请区分清概念

作为“专业的开发人员”，请在了解了某个技术之后，再对其发表见解吧，最起码你得知道这个技术是怎么回事吧？如别人说“LINQ to SQL已死”，然后就有人跟着说“幸好我没用LINQ”，这又关LINQ啥事了。博客园老赵曾经在6月份写过一篇文章《觉得有必要来澄清几组重要概念》，其中介绍了LINQ以及LINQ to SQL的区别，但是很遗憾，社区中不能正确区分LINQ和LINQ to SQL的朋友太多了，看到这些言论，让我们为老赵这篇文章默哀一分钟吧。

再强调一遍：LINQ to SQL只是LINQ家族中众多Providers中的一个而已，这是真的，请不要怀疑，不要把LINQ等同于LINQ to SQL，如果觉的LINQ to SQL字母太多了，可以使用L2S来代替，但请不要使用LINQ来代替LINQ to SQL。

请收起LINQ无用论

“LINQ很垃圾”，“拒绝LINQ”，看到这些，真的有些悲哀，LINQ仅仅是一个语言特性，它能够让我们在编写代码时使用内置的查询语法对于数据集合进行操作，提高我们的开发效率，仅此而已。当然如果你的数据集合来源不同，会对应不同的Providers。既然拒绝LINQ，为何不干脆连泛型、数组以及.NET Framework中内置的基础类库等等一起拒绝，甚至于拒绝C#语言，而回到所谓的“本机代码”上去呢，直接编写二进制的“01101100”程序是不是比C#语言更方便，更快速？如果是，请原谅，我错了，我道歉。

再强调一遍：LINQ仅仅是一个语言特性而已，请收起LINQ无用论。

后记

写下本篇文章，其实不是想针对某个人，只是看到大家都在误解LINQ，甚至有些初学者因为看到“LINQ已死”的谬论，都不敢去学习，去使用了。所以忍不住站出来说几句话，如有得罪您的地方，请见谅！

相关文章：

微软决定废弃两个框架