晚上抽空看了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正是来自编译器的支持。
![](http://image.it168.com/cms/2008-1-17/Image/200811763914.gif)
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已经开始走向更成熟,先进和自信的一面
不过一直挺喜欢Video这种形式,因为即使你不懂语言,看着节目照葫芦画瓢,也能获得很多知识和体验,想想如果以前有Video,那么就不用写文字1,2,3的说了。4年以后图形的压缩、存储以及网络带宽有了一定的提高,但似乎还没有到了极大丰富的地步。
比着Mtaulty的录像,自己也演练了5+个小时,开始喜欢起来,因为感觉之前看的或研究过的CSLA.NET, Bese4.NET,Wilson ORMapping 似乎被收编和再次统一,而且从LINQ to SQL来看,会变得更为底层,因为在平台层面操作系统是最底层的,在.NET层面CLR是最底层的,但在编程语言这个层面,没有比编译器更为底层的了,而LINQ正是来自编译器的支持。
![](http://image.it168.com/cms/2008-1-17/Image/200811763914.gif)
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已经开始走向更成熟,先进和自信的一面