晚上抽空看了Mtaulty有关Linq to SQL的N集连播，大呼过瘾，看完才有不少感概，国外DPE的这些Evangelist真是在传教解惑，如果换成中文的，哪估计能普及更多中国的.NET 爱好者，想想几年前自己在DPE的时候，天天有数字的压力，每每像个小弟一样跟着Sales老大跑前跑后，是明白了很多的销售的道理，当时感觉自己像蜻蜓点水，不过话也说回来，那时候还没有这么多的方式，有是播又是拍、又是Blog还能即时通讯、声音文字图像无线网络一起上，手段之多方法之强啊。
不过一直挺喜欢Video这种形式，因为即使你不懂语言，看着节目照葫芦画瓢，也能获得很多知识和体验，想想如果以前有Video，那么就不用写文字1，2，3的说了。4年以后图形的压缩、存储以及网络带宽有了一定的提高，但似乎还没有到了极大丰富的地步。
比着Mtaulty的录像，自己也演练了5+个小时，开始喜欢起来，因为感觉之前看的或研究过的CSLA.NET, Bese4.NET，Wilson ORMapping 似乎被收编和再次统一，而且从LINQ to SQL来看，会变得更为底层，因为在平台层面操作系统是最底层的，在.NET层面CLR是最底层的，但在编程语言这个层面，没有比编译器更为底层的了，而LINQ正是来自编译器的支持。
JJX在评测网发了一个帖子，说到Orcas 的即将发布，我们将得到两个orm(暂且这么叫吧）框架 : ado.net entity framework 和linq to sql ，未来你会主要采用哪种进行开发呢？
这是一个不错的问题，我记得当时回答，两个都会用，geniusleft则说,aef 更适合大项目。
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(数据源或对象源)的数据集成和查询的能力以及便利(内置的表达式，操作语句，代码生产效率，性能等等)
最后是Entity Client，这个一个新型的API，也就是专门用来访问实体源或实体数据模型，Entity Client使用自己的语言-Entity SQL (eSQL)，它也是ADO.NET提供的另外一个数据源提供驱动，你可以用理解SqlClient一样来理解Entity Client，它是另外一条访问实体数据模型的途径，它存在的意义有两个，第一它的访问性能会高，第二，EntityClient返回的结果是 dbDataReader，这意味着你可以使用统一或者你非常熟悉的代码经验比如你使用ADO.NET操作 SQL Server, Oracle，MySQL的技能对查询回来的数据进行娴熟地处理，抑或是如拌凉菜般地翻腾这些数据:)
作为一个顾问和实践者，我们首先要去做，然后要面临给予自己和其他的人一些建议，在未来的6个月到一年：
1. LINQ的出现展示了一种最底层的新型张力，任何现代编程语言最重要的能量和动力在这个语言的编译器，LINQ的出现让所有有关语言先进性争论的时代划句号，作为技术人员你需要察觉到这种变化和带来的影响
2. 从目前的Orcas Beta1版本来看，建议你在未来的6-12月优先学习C# 3.0和LINQ，掌握新型的表达式、语法和语句，这是未来编程语言中和For,IF语句一样的基本功，而每个开发人员需要熟练的使用这些语句，当然能够研究和搞明白这些新语句的背后的实现和原理，那是最佳的
3.对于那些已经掌握C#3.0和LINQ的中级的开发人员来说，在LINQ to SQL(LINQ2SQL)和ADO.NET Entity Framework来说，可以优先考虑学习和研究LINQ to SQL，并将其这种技术在项目或应用中做以实践
4.ADO.NET Entity Frameworkd的 Entity Desiger出来之前，保持对它的关注，而不用花太多的时间，另外从一个开发人员的角度来看，ADO EF不是必须的，甚至在设计人员特别是Domain Model Drivening的人员要关注和准备的，当然这些在6个月之后考虑和研究都不晚
5.Visual Studio Orcas的发布日期依然是一个很关键的因素，可以预见的是C# 3.0和LINQ将会在人们期望和愿望实现的时间点发布，但涉及到ADO.NET Entity Framework的部分有多少，这个要观察和注意，但反过来说，有了LINQ和LINQ to SQL已经让我们感到物有所值了
6.在你的项目中考虑新的功能特性对应用架构的影响，同时也尽可能多练习在ASP.NET这种传统的开发技术下LINQ和C# 的应用
7.继续保持对Visual Studio Orcas的关注，因为.NET 3.5或.NET 4.0已经开始走向更成熟，先进和自信的一面
597
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
