问题描述
我在深圳面试了很多家，他们有的就不知道什么是linq,有的说linq执行慢，好像还没有看到哪个公司用LINQ
解决方案
解决方案二：
因为这些公司的程序员傻呗。他们不能完整掌握C#语法，不会用。
解决方案三：
一叶障目？有强大的工具放着不用，岂不可惜。如果说LinqtoEntity或者LinqtoSQL慢，让他们受不了，那么LinqtoObjects与LinqtoXml还是很强大的。
解决方案四：
很正常的哇，一般公司都有自己的orm之类的东东，都是按照那个做的，不懂或者不知道也很正常不过说linq慢的就只是把linq用在了sql方面，而不是linqtosource
解决方案五：
初级程序员搞不懂委托、泛型、接口这最基本的3个C#语法，你说他怎么用LINQ。
解决方案六：
初级程序员的另一个问题是，根本就不知道什么是linq，他们分不清linq和linqtosql，明明是C#语言特性，非认为是什么ORM框架。实际上他们除了精通各种GridView、repeater的绑定，对其他名词大多是一知半解。
解决方案七：
不是哪个公司都去赶潮流的，每个公司都有自己的需求
解决方案八：
LINQ带来的，不仅仅是数据库的这一小块，非得把LINQ限定为一种数据库的存取封装技术或者ORM工具，本身就是对LINQ的误解。
解决方案九：
一个公司找来的程序员连基本的C#语法有一半都不会，还好意思说自己不追赶潮流。LINQ只是把委托、接口、泛型三个概念作为一个C#程序员的门槛提出来了。我可以直接地说，这些三角猫的程序员其实本来就是滥竽充数的，到了C#3以后越发混不下去了。
解决方案十：
引用6楼shwicho的回复:
不是哪个公司都去赶潮流的，每个公司都有自己的需求
这不是仅仅是潮流。仅举一个局部的例子：没有LINQ之前，我们要花多少精力去构造插入算法、查找算法，以及其他的一些工作。当我们可以有更好的工具，让我们从底层的算法纠缠中脱身，而把业务与时间更多地放在业务需求上时，为什么要说“NO!”呢？
解决方案十一：
引用9楼abbey的回复:
引用6楼shwicho的回复:不是哪个公司都去赶潮流的，每个公司都有自己的需求这不是仅仅是潮流。仅举一个局部的例子：没有LINQ之前，我们要花多少精力去构造插入算法、查找算法，以及其他的一些工作。当我们可以有更好的工具，让我们从底层的算法纠缠中脱身，而把业务与时间更多地放在业务需求上时，为什么要说“NO!”呢？
他们不要说算法，连循环都不愿意写。所有东西都围绕控件。你不是要读取数据吗？绑定。你不是要传值么？传控件。你不是要排序么？控件排序。
解决方案十二：
引用10楼caozhy的回复:
他们不要说算法，连循环都不愿意写。所有东西都围绕控件。你不是要读取数据吗？绑定。你不是要传值么？传控件。你不是要排序么？控件排序。
要用积木搭个漂亮结实的房子，也得下点功夫啊
解决方案十三：
一个垃圾的软件公司，根本不需要合格的程序员。首先他们天天招人，为什么呢？因为他们需要足够足够便宜的软件工人，让他们做初级的，可以替代的工作。并且压低工资，不行就换一个是他们的第一法则。然后是他们招来的人，只要工资合适，什么人都招。很多人庆幸自己忽悠了公司的面试官，以为讨了便宜，实际上没有本事只能给人家忽悠，哪有忽悠人家的资本。
解决方案十四：
扩展方法、匿名类、lambda表达式—这是让C#变得丰满和优雅的重大改进。
解决方案十五：
天天来csdn的人有一种错觉，就是程序员都是这么菜。实际上这里大部分问问题的都是学生（糊个作业，以后改行的），要不就是青鸟等技校出来的代码工人，要不根本就不是写程序的外行，跑这里找免费苦力的。实际上应该不应该用LINQ这种可笑的问题在程序员中早就达成了共识。如同问厨师用不用味精和盐一样毫无意义。
解决方案：引用13楼abbey的回复:
扩展方法、匿名类、lambda表达式—这是让C#变得丰满和优雅的重大改进。
所以很可笑的问题就是，很多人对C#的认识还停留在C#1.0时代，认为C#和Java差不多。Java程序员拿起VisualStudio就能写C#程序。
解决方案：引用15楼caozhy的回复:
所以很可笑的问题就是，很多人对C#的认识还停留在C#1.0时代，认为C#和Java差不多。Java程序员拿起VisualStudio就能写C#程序。
C#一直在进步。仅就我涉及的部分而言，泛型、可空类型、扩展方法、匿名类以及lambda表达式，以及由此衍生出的其他一些技术，是让我越发喜欢它的原因。甚至如var这样的语法糖，也令我惊喜不已。
解决方案：引用6楼shwicho的回复:
不是哪个公司都去赶潮流的，每个公司都有自己的需求
这句话说的荒谬就在于，LINQ是C#语言实现排序、分组、筛选、统计数据的最佳方式。哪一个搞软件的没有排序、分组、筛选、统计数据的需求。明明是武大郎个子矮，非要赖人家裤子长。
解决方案：lambda是c++11的标准。有些公司stl都不让用更别说是lambda了。如果你用c#写个tcp的服务器你会用lambda？？如果你做winform界面。人眼是1/24=0.04秒。你的处理时间只有这么短。不在这个时间处理完。你的东西就卡了。你用会lambda??c#已经慢很多。再用这个谁受的了。小项目，只是数据相关的东西用用还差不多。
解决方案：引用16楼abbey的回复:
引用15楼caozhy的回复:所以很可笑的问题就是，很多人对C#的认识还停留在C#1.0时代，认为C#和Java差不多。Java程序员拿起VisualStudio就能写C#程序。C#一直在进步。仅就我涉及的部分而言，泛型、可空类型、扩展方法、匿名类以及lambda表达式，以及由此衍生出的其他一些技术，是让我越发喜欢它的原因。甚至如var这样的语法糖，也令我惊喜不已。
C#与其说一直在进步，不如说是在奋力追赶其他主流编程语言。扩展方法可能挺不错，但是Ruby这种支持原型的语言，可以动态添加方法，只能说C#的扩展方法是在藏拙。var的首要动机是为了配合匿名对象。但是和函数式编程语言相比，C#远远不够。泛型、可空类型固然不错，可是动态语言完全取消了类型的自由C#也望尘莫及。我赞同《黑客和画家》这本书的观点。现代软件为什么推崇动态语言？因为软件的复杂度在提高，硬件成本在降低。现在软件越来越难以将需求、设计和编码区别开来。优秀的编程语言应该是一只铅笔，允许开发者一边编码，一边设计，一边修改，一边探索最佳的做法。而静态语言更像一只钢笔。VS11看来包含的C#改进不大，可能叫C#4.5。我不知道C#5会往哪里走。但是静态语言要保持和之前的兼容性，还要不断追赶主流语言，恐怕遇到的阻力越来越大。
解决方案：该回复于2012-03-05 10:13:17被版主删除
解决方案：引用16楼abbey的回复:
C#一直在进步。仅就我涉及的部分而言，泛型、可空类型、扩展方法、匿名类以及lambda表达式，以及由此衍生出的其他一些技术，是让我越发喜欢它的原因。甚至如var这样的语法糖，也令我惊喜不已。……
赞一个
解决方案：他们还守着老旧的编程方式，没有进取意识。
解决方案：同意上面大侠的意见，这个跟公司或者说开发团队的水平有关，就好比你跟整天垒猪圈的人谈欧式还是中式设计风格一样道理。
解决方案：想用就用嘛又不是很难
解决方案：精彩，，，，，
解决方案：不错。。。有些公司就不敢用新技术，想花较少的钱招牛X的程序员，那怎么可能呢？公司不愿出血，那怎么能用得上新技术了。公司的总监不看看新闻怎么能知道有新技术叱有些公司更恶，招一下java方向的当总监，而程序员用的是.net
解决方案：引用17楼caozhy的回复:
引用6楼shwicho的回复:不是哪个公司都去赶潮流的，每个公司都有自己的需求这句话说的荒谬就在于，LINQ是C#语言实现排序、分组、筛选、统计数据的最佳方式。哪一个搞软件的没有排序、分组、筛选、统计数据的需求。明明是武大郎个子矮，非要赖人家裤子长。
弱弱的问一句：Linq的底层实现是什么？Linq实现排序，在底层是如何完成的？
解决方案：LZ会了linq再来看他们说的话吧
解决方案：引用4楼caozhy的回复:
委托、泛型、接口这最基本的3个C#语法，你说他怎么用LINQ。
LINQ是"委托、泛型、接口"，但"委托、泛型、接口"并非LINQ。LINQ是有用但不必神化它。
解决方案：引用29楼z81434362的回复:
引用4楼caozhy的回复:委托、泛型、接口这最基本的3个C#语法，你说他怎么用LINQ。LINQ是"委托、泛型、接口"，但"委托、泛型、接口"并非LINQ。LINQ是有用但不必神化它。
谁告诉你LINQ是“委托、泛型、接口”的？
解决方案：引用27楼dengyouhua的回复:
引用17楼caozhy的回复:引用6楼shwicho的回复:不是哪个公司都去赶潮流的，每个公司都有自己的需求这句话说的荒谬就在于，LINQ是C#语言实现排序、分组、筛选、统计数据的最佳方式。哪一个搞软件的没有排序、分组、筛选、统计数据的需求。明明是武大郎个子矮，非要赖人家裤子长。弱弱的问一句：Linq的底层实现是什么？Linq实现排序，在底层……
首先，LINQ的排序是稳定的，并且依赖HashCode，猜测它可能是加上稳定的堆排（很有可能，因为它是延迟的）或者快排。LINQToXXX则依赖其提供者的排序。
解决方案：有自己的开放框架，自然就不选Linq......
解决方案：Ctrl+CandCtrl+Visenoughforsomecompanies.
解决方案：能解决实际问题，能赚到钱才是王道，在讨论用什么工具只能说明还是儿童级的程序员
解决方案：新技术不一定都好用，有时候无线发报机比手机可靠。
解决方案：我也有个疑惑，不知道为什么很多linq程序员看不起数据库端排序统计，而对linq中的排序统计很推崇。是真心不懂，本人也对linq的底层实现不明白。
解决方案：引用36楼hwbox的回复:
我也有个疑惑，不知道为什么很多linq程序员看不起数据库端排序统计，而对linq中的排序统计很推崇。是真心不懂，本人也对linq的底层实现不明白。
因为其实linq的核心在与后面的表达式树解析上，所以如果你正确的提供了linq的provider，他会自动生成对应的数据库版本的语句，所以无所谓是linq去排序，还是数据库端排序统计，他们结果都是一个故事当然目前linq的provider的缺点也存在，那就是暂时还没有啥很好的办法去简单处理多表连接这块的东西，除非在去人为设定一套map规则比如EF的codefirst
解决方案：linq语法很有意思
解决方案：linq执行的时候也是翻译成sql语句才执行的
解决方案：。。搞晕我了
解决方案：引用36楼hwbox的回复:
我也有个疑惑，不知道为什么很多linq程序员看不起数据库端排序统计，而对linq中的排序统计很推崇。是真心不懂，本人也对linq的底层实现不明白。
因为排序、统计作为很多算法的基础，本身是程序员创建一般代码的需要。这样的代码并非依赖用户界面或者数据库。“胶水程序员”（虽然我认为这种人根本不算程序员，因为程序员必然是编写程序、创造代码的）不需要“编写和创造代码”，他们的一般工作（我猜测和你描述得很类似）就是把后端的数据库和前端的用户界面粘贴起来，凑出一个可用的程序。因为他们编写的代码只是将现有的程序集成起来，而本身不具备价值类似胶水而得名。因为他们不编写代码，所以他们对改善程序员效率的技术并不关心。他们关心的是那些用户界面和数据库技术中已经有的功能。当然一个良好的胶水程序员应该知道，除了数据库以外，Grid控件等也提供了排序。但是对于程序员来说，你的任务是创造开箱可用的代码，如果程序员为胶水程序员提供的东西本身沾满胶水，那么你就会在这个论坛看到这样的提问了：“请问引用正则表达式库需要如何配置数据库”“请问我用的是控制台程序没有办法添加ListView如何传递Session”。
解决方案：引用39楼smg008的回复:
linq执行的时候也是翻译成sql语句才执行的
又来一个根本连LINQ是什么都不知道的。为什么那么多人在论坛里面发表高见之前就不能先了解下自己评论的是什么呢？
解决方案：linq其实很好用的。我一直都用它，ado.net基本都不用
解决方案：我觉得这就跟当初面向对象出来的时候大部分人还都是结构化编程一样
解决方案：引用4楼caozhy的回复:
初级程序员搞不懂委托、泛型、接口这最基本的3个C#语法，你说他怎么用LINQ。
确实啊，LINQ在这三方面利用的淋漓尽致
解决方案：引用41楼caozhy的回复:
引用36楼hwbox的回复:我也有个疑惑，不知道为什么很多linq程序员看不起数据库端排序统计，而对linq中的排序统计很推崇。是真心不懂，本人也对linq的底层实现不明白。因为排序、统计作为很多算法的基础，本身是程序员创建一般代码的需要。这样的代码并非依赖用户界面或者数据库。“胶水程序员”（虽然我认为这种人根本不算程序员，因为程序员必然是编写程序、创造代码的）不需要“……
我在使用linq时可以感觉到你说的那种程序员友好性，但某种程度上我一直认为他是一种语法糖。我说的不明白是说，这玩意和ORM框架在，数据库的数据获取操作上有什么本质不同，而在操作本地数据上，又与ADO.net中的DATASET有什么不同（除了语法层面上的易用以外）。
解决方案：引用42楼caozhy的回复:
引用39楼smg008的回复:linq执行的时候也是翻译成sql语句才执行的又来一个根本连LINQ是什么都不知道的。为什么那么多人在论坛里面发表高见之前就不能先了解下自己评论的是什么呢？
这个回复和37楼的回复把我搞糊涂了。那么真相是什么呢？
解决方案：应该看情况而定吧LINQ在平常是很好用但如果数据量太大的话用LINQ确实会降低效率有些时候最plain的code往往效率最高我的习惯就是在数据量大的情况下尽量不用.net封装很多的东西
解决方案：扩展方法还是可以用,匿名方法和lambda表达式就要非常谨慎了,一般情况下都建议用命名方法,因为涉及到变量的作用域问题,用匿名方法和lambda表达式很容易产生比较隐蔽的Bug.特别是在多线程处理的时候,比如threadstart方法就最好不要用lambda表达式.不要觉得语法上新奇就用,而是要弄明白其机理,以决定什么时候可以用,什么时候要不用.另外linq的结果是一个查询,但这个查询的枚举的时候是没有规律的,在需要保证数据访问顺序的时候还是要数组访问方式.而且查询在迭代访问过程中是不能改变源的.
解决方案：linq的本质是扩展方法,linq的那种查询表达式到最后都会被编译器翻译成扩展方法的.跟ESQL不是一回事情.