博客园  :: 首页  :: 联系 :: 管理

转:LINQ to SQL(LINQ2SQL) vs. ADO.NET Entity Framework(ADOEF)-ccBoy版

Posted on 2007-07-27 17:14  sunrack  阅读(1333)  评论(2)  编辑  收藏  举报
好爽，晚上抽空看了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 更适合大项目。

具体的录像在下面，都是wmv格式，可以直接观看，但建议download下来，Video的另外一个好处是，可以暂停、继续，反反复复，学习和实践就应该这样 期待着第十一集，第十二集。。。。。。

昨天看完录像后，我也去网上寻找了一下，战果如下： 从上面的文章可以看到
  • 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已经开始走向更成熟，先进和自信的一面
离我写面向.NET开发人员的Ajax 技术平台策略这篇文章已经快一年,写到最后我本来也想将其命名为面向.NET开发人员的数据编程(Data Programming)技术的平台策略，但想想目前的LINQ/ADO EF和之前的Ajax还不同，还有很多在Beta和变化中，唯一我们需要的是在无所在之地(The placeless place) 安住和等待

ccBoy

v0.6 : 2007/03/23
v0.8 : 2007/03/24
v0.9 : 2007/03/25
v0.91:2007/03/27

版