LINQ本身就是一组语言扩展，有助于查询、可读性和减少代码。LINQ to SQL是一种OR映射器，但它并不是特别强大。实体框架通常被称为OR映射器，但它做得更多。
还有其他几个LINQ toX实现，包括LINQ to NHibernate和LINQ to LLBLGenPro，它们以与实体框架大致相似的方式提供OR映射和支持框架。
如果你只是在学习LINQ，我建议你坚持使用LINQ to Objects来了解它，而不是深入到更复杂的口味中：-)
LINQ根本不是ORM。LINQ是一种查询"东西"的方式，或多或少可以被视为不同事物(IEnumerables)的类似SQL的语言扩展。
可以查询各种类型的"资料"，其中包括SQL Server数据库。这被称为LINQ to SQL。它的工作方式是基于DB和查询的结构生成(隐式)类。从这个意义上说，它更像是一个代码生成器。
LINQ to SQL不是ORM，因为它根本没有试图解决对象关系阻抗不匹配的问题。在ORM中，您可以设计类，然后手动将它们映射到表，或者让ORM生成数据库。如果出于任何原因(通常是重构、重整化、非规范化)更改数据库，那么很多时候都可以通过更改映射来保持类的原样。
LINQ to SQL不执行任何操作。您的LINQ查询将与数据库结构紧密耦合。如果您更改DB，您可能也必须更改LINQ。
LINQ to SQL(Visual Studio 2008的一部分)是OR映射器。
LINQ是一种新的查询语言，可用于查询许多不同类型的源。
LINQ本身不是ORM。LINQ是允许查询SQL等对象的语言特性和方法。
"LINQ to SQL"是一个允许我们对SQL强类型对象使用LINQ的提供程序。
我认为一个确定平台或代码块是否显示O/R-M特征的好测试很简单：
戴上解决方案的帽子，开发人员(或他/她的代码生成器)对数据库内部的内容有任何直接的、不可抽象的了解吗
有了这个标准，不同LINQ实现的答案可以是
是的，数据库模式的知识完全包含在您自己的卷中，LINQ使用O/R-M代码层或
否，数据库模式知识分散在整个应用程序中此外，我将把这个特征扩展到O/R-M的三个简单级别。
1.放弃。这是一个由几个开发人员组成的小型应用程序，对象/数据模型没有那么复杂，也不会经常更改。小型开发团队可以保持领先地位。2。在数据访问层中滚动自己的。通过在数据访问层进行一些可管理的重构，相对较小的开发团队可以在中间层实现所需的O/R-M功能。足以让整个团队保持一致3.企业级O/R-M规范定义/开销引入工具。在某种程度上，需要将所有开发人员都放在同一个页面上，这只会淹没形式带来的任何开销。没有必要在这种复杂程度上重新发明轮子。N-hibernate或(粗略的)V1.0实体框架就是这种规模的例子
关于更丰富的分类，我从中借鉴并简化了它，请参阅Ted Neward的经典文章
nbsp http://blogs.tedneward.com/2006/06/26/The+越南+Of+计算机+科学.aspx
他将O/R-M治疗(或放弃)归类为
1.放弃开发人员只需完全放弃对象，返回到不会造成对象/关系阻抗不匹配的编程模型。虽然令人反感，但在某些情况下，面向对象的方法会产生比节省更多的开销，而且ROI根本无法证明创建富域模型的成本是合理的。(【Fowler】对此进行了深入的讨论。)这相当巧妙地消除了问题，因为如果没有物体，就不会出现阻抗失配2.全心全意的接受开发人员只需完全放弃关系存储，而是使用一种适合他们选择的语言看待世界的存储模型。对象存储系统，如db4o项目，通过将对象直接存储到磁盘来巧妙地解决问题，消除了许多(但不是全部)上述问题；例如，没有"第二个模式"，因为唯一使用的模式是对象定义本身的模式。尽管许多DBA一想到就会晕倒，但在一个越来越面向服务的世界里，它避开了直接数据访问的想法，而是要求所有访问都通过服务网关，从而封装了存储机制，使其免受窥探，想象开发人员以比DBA更容易使用的形式存储数据是完全可行的3.手动映射开发人员只需接受手动解决这不是一个困难的问题，并编写直接的关系访问代码来返回与语言的关系，访问元组，并根据需要填充对象。在许多情况下，这些代码甚至可能是由检查数据库元数据的工具自动生成的，从而消除了对这种方法的一些主要批评(即"编写和维护的代码太多")4.接受O/R-M限制开发人员简单地接受了没有办法有效而轻松地结束O/R不匹配的循环，并使用O/R-M来解决80%(或50%或95%，或任何合适的百分比)的问题，并使用SQL和基于关系的访问(如"原始"JDBC或ADO.NET)将它们带过O/R-M会产生问题的区域。然而，这样做会带来相当大的风险，因为使用O/R-M的开发人员必须意识到O/R-M解决方案在其中所做的任何缓存，因为"原始"关系访问显然无法利用该缓存层5.将关系概念集成到语言中开发人员只是接受这是一个应该由语言而不是库或框架来解决的问题。在过去的十年或更长时间里，对O/R问题解决方案的强调一直集中在试图让对象更接近数据库，这样开发人员就可以专注于单一范式中的编程(当然，该范式是对象)。然而，在过去的几年里，人们对Ruby等具有更强集和列表支持的"脚本"语言的兴趣引发了一种想法，即也许另一种解决方案是合适的：将关系概念(本质上是基于集的)引入主流编程语言，从而更容易弥合"集"one_answers"对象"之间的差距。到目前为止，这一领域的工作一直很有限，主要局限于研究项目和/或"边缘"语言，但一些有趣的工作正在社区中获得可见性，例如Scala或F#等函数/对象混合语言，以及直接集成到传统的O-O语言中，，如微软针对C#和Visual Basic的LINQ项目。不幸的是，SQL/J战略就是其中一项失败的努力；即使在那里，这种方法也是有限的，不寻求将集合合并到Java中，而是简单地允许由翻译器对嵌入式SQL调用进行预处理并将其翻译成JDBC代码6.将关系概念集成到框架中开发人员只是接受这个问题是可以解决的，但只需要改变视角。开发人员不再依赖语言或库设计人员来解决这个问题，而是对本质上更具关系性的"对象"采取不同的看法，构建更直接地围绕关系结构构建的领域框架。例如，开发人员不是创建一个将其实例数据直接保存在对象内部字段中的Person类，而是创建一个在RowSet(Java)或DataSet(C#)实例中保存其实例数据的Person类别，它可以与其他RowSets/DataSet组装成一个易于发送的数据块，用于针对数据库进行更新，或者从数据库解包到各个对象中
Linq To SQL使用dbml设计器yes，否则Linq只是Enumerables的一组扩展方法。