LINQ to SQL全面概述
在向大家详细介绍LINQ to SQL之前，首先让大家了解下LINQ to SQL不能算纯粹意义上的ORM，因为它支持的数据库种类和类型还不够多，然后全面介绍LINQ to SQL。
LINQ to SQL 目前只支持SQL Server(SQL Server Compact版本正在开发中)，有迹象表明，也可能会支持DB2，Informix IDS，Oracle官方说法是他们在关注Linq的进展，VistaDB， MySQL。。。但可以预见的是Linq如果要在2007年底RTM，那么要支持其它数据库的时间上，并不多，甚至我在Weblog上看到说，对SQL Server Compact的支持都不包含在LINQ v1版本计划中。不过，MS，IBM，Oracle他们如果真决心做，那么时间不是问题上面的结论如果成立，那么我的第一观点是，LINQ to SQL不能算纯粹意义上的ORM，因为它支持的数据库种类和类型还不够多
从技术的先进性和难度来看，Java Persistence API和Linq是解决不同层面问题的两种技术，并且从开发人员的角度来看，Java Persistence API没有Touch到Linq关注的层面，上面我说了，从编程语言的角度来看，LINQ是来自最底层编译器和开发语言的支持，Java Persistence没这么底层；另外对于Java Persistence API，Adopt已有的ORM技术比如Hibernate, TopLink, JDO方面，Java Persistence API更像已有Java ORM的集大成者新建的一个API，而LINQ to SQL，LINQ to DataSet，LINQ to XML，LINQ to Entities，LINQ to Object，LINQ to Flickr, LINQ to NHibernate, LINQ to LDAP 已经都是板上定钉的事情，所以从设计上来看，LINQ更大气和宏观，因为一旦从编译器和开发语言的层面的支持，那么其融合渗透和应用的程度就相当高的，我认为其"亲和力"相当强悍
ADO.NET Entity Framework(ADO EF)更多的是一个实体或概念设计的服务框架，是现实的实体和实体间的关系映射到将对象层，CLR 类和它们之间的关系上，甚至ADO.NET Team也避免让ADO EF概念上变成一个类似ORM的设计工具，ADO EF强调的三层{概念层/实体层(Conceptual layer), 元数据层(Source schema)和影射层(Mapping layer)}的灵活、独立和松散耦合，从而使得你可以将一个概念层/实体层通过定义多个影射层从而映射到多个不同的数据库上，而这一点LINQ to SQL做不到，首先LINQ to SQL不支持实体的多重继承(支持有限的继承)，甚至有评论说LINQ to SQL RTM之前都不会获得many-many relationships的支持，LINQ to SQL更多的是使用dbml属性非常紧耦合地绑定到一张表的某些特定的数据库字段上。也就是说LINQ to SQL没有这么多层，另外它强调的是编程语言对数据查询和分析的结构化支持(从编程语言的层面)
理论上ADO EF是一个浩大大工程的框架，从而能够更好的支持流行的Domain Model Driven的开发，这要求它要有三层的设计工具展现你的设计，突现和定位你的实体关系，要求工具能够根据实体层产生数据库的脚本或是反向工程，同时需要有精度极高同时有非常Smart的代码生成工具和界面，同时，而目前Orcas Beta1单薄的的EDM Wizard根本不足以完成这些要求，更早先发布的Entity Data Model Designer Prototype已经成为丰碑快不可超越，看看这里有比较漂亮的一个设计器的录像--很酷
“Entity Framework the March CTP and Beta 1 are almost identical. There's some last bit of features that we're busily working on now that will appear in Beta 2 and the Orcas Release”这意味着Orcas Beta1和March CTP中 ADO EF变化并不大(ccBoy建议：在Orcas Beta1你可以精力重点放在 LINQ to SQL上)，甚至有人认为Orcas's Entity Framework 进度的重大的标志在于Orcas能够提供出优良的EDM Designer，满足我们上面说的工程需求，所以Orcas Beta2将是ADO EF的一个重大里程碑，所以结论是，ADO EF和 LINQ to SQL侧重点上看两者的关注点非常不同，相比来说ADO EF开发或性能上会奔重些，但是ADO EF倾向Domain Model Driven和支持更多的流行的数据库或数据源，但ADO EF绝对不是一个简单的ORM Tools，理解成实体框架和对象服务层技术会更宏观，这里面LINQ成为ADO EF中很小的一个低层支撑技术，我刚刚说了LINQ的亲和力
从技术开发的角度来看，如果你的实体/业务模型(或者称为问题域)和已有的数据模型不匹配的时候，你需要考虑ADO EF，反正如果你的实体/业务模型(或者称为问题域)和已有的数据模型匹配，那么LINQ to SQL 会是不错的选择至于LINQ to Entities和LINQ to SQL，上文已经说的比较清楚(思归翻译的版本)，我总结一下，相同点是，LINQ to Entities是LINQ to SQL的一个超集或加强版(Superset)，你看到两者的Feature对比上，LINQ to Entities更重，它运行或说让你在一个概念数据模型上(Conceptual data model)，你对对象的查询是发生在这一层
那么不同的地方在于，你使用LINQ to SQL的时候，你的映射，产生的CLR/.NET类是和你的数据/数据库模型紧耦合或绑定的，如果你改变对象模型，那么你要直接修改这些类，同样如果数据模型改变，你要使用重新生成对象代码，而ADO EF在数据/数据库模型上建立一个概念层/实体层，这使得你要先定义概念层/实体层，接着建立数据/数据库的脚本(描述)，然后在一个影射层建立你的实体和数据之间的逻辑映射，这使得业务和数据源之间有了很好的藕合度和隔离。而LINQ to SQL无法达到这样的效果，另外LINQ to Entities也直接带有了ADO EF提供的另外一些强项，比如实体的继承(Entity Inheritance )，实体的组合(Entity Composition)
Entity SQL (eSQL)更多的时候，它是SQL语句的变体是完全面向查询语言的(Query Language)，但是是对应的是对实体数据模型的查询，是对实体，实体中的属性进行查询，更多的时候Entity SQL 是面对ADO EF的Object Services，对象服务是ADO EF中能够将实体像对象一样工作和操作的服务，事实上Object Services往往是事实上的内存对象数据库，当然在这里你只能查询对象或实体并获得它们，你不能是使用SQL DML语句一样，Update或Deleted对象或实体(当然未来可以，现在v1版本是做好查询)，当我们要和上面说的概念层/实体层交互的时候，第一你可以使用Entity SQL (eSQL)，第二你要使用LINQ to Entities，Entity SQL (eSQL)是文本和字符的，所以它支持组合(composable)，比如子查询，而后你明白所有的LINQ to XXXX，其实就是说你如何让你在编程语言这个层面，很快地享受到LINQ针对XXXX(数据源或对象源)的数据集成和查询的能力以及便利(内置的表达式，操作语句，代码生产效率，性能等等)