|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
因为各系统的API不同,代码调用API编写程序就会遇到很多不兼容的地方,比如net网页编程改写后的Serv-U就不能在手机上执行,手机的游戏也不能直接在微机上执行。社区关于ADO.NETEntityFramework和LINQtoSQL的最年夜不满,就是它不撑持变动跟踪。但只要在你毗连到高低文对象的时分,你才能够修正对象并把它们保留回数据库。就像数据库毗连那样应当十分快,一旦该高低文对象超越局限,数据对象本色上就进进只读形态。从头附加它们到新高低文往返写它们的变动,这并非一个好举措。
微软回绝办理该困难。他们没有像年夜多半ORM库那样,在数据对象外部增加变动跟踪,改成加倍存眷POCO大概“复杂初始C#对象”。
在EntityFramework计划博客上,微软的三位开辟职员归纳综合了一些盛行的数据库会见办法。第一个是ADO.NETDataSet,它可以回写变动的汇合到数据库。他们列出了利用ADO.NET数据集的四个“成绩”,但都意义不年夜。它们都会合在经由过程不成信界限发送变动汇合,也并没有太粗心义。数据集会见和ORM库用来污染数据,而这本该使用程序本人来处置。
下一个是DTO或数据传输对象。这仅是一种幻想的说法,“我们先把一切数据安排在某些对象中,然后你来处置它。”这与比来的会商其实不相干,但的确申明了他们的设法。
该话题接着复杂地提到REST。如今,我们晓得EntityFramework团队已完整健忘本人应当创建甚么。至于他们所说的“方针”,跟着对EntityFramework举行N层改善,我们想办理一些不异的成绩空间,比方数据集,但要避开它一些次要成绩。 实际上,我们倾向于供应用于构建的模块,它正吸引开辟职员在普遍的架构之上创建办理计划。比方,我们要给DTO撑持者供应完美的控件,同时下降在办理复杂计划时所接受的疾苦。 如今成绩已相称了然:EntityFramework不想成为另外一个ORM,它想成为每一个人所需的统统。就像我们一次又一次看到的那样,这类办法不会让人中意。看一下该团队的声明,除这两点,针对图象中做变动的成绩,另有一些更风趣的通用暗示法,但一样平常来讲,它们有着不异的弱点:给它们供应办理计划其实不能受权给用户把持的级别,这也是最庞大的办理计划和最成熟的形式所必需的。 接着,关于N层使用程序中所形貌的变动汇合,EntityFramework并没有界说本人共同的暗示法。换言之,它供应基础的构建模块API,这将增进暗示法的普遍利用。 因为他们不克不及针对操纵变动汇合的成绩,供应完全的办理计划,他们将不会给开辟者带来任何工具。开辟职员不能不在EntityFramework之上创建本人的ORM,假如他们的确要在高低文内部操纵数据的话。
本文的余下部分是相称冗杂的示例,它关于怎样利用新API来实行变动跟踪。这包含创立接口(比方IEntityWithChanges)、像GetEntityState那样利用手写的办法举行映照、大概在一个办法中二者都利用,该办法吸收高低文对象、实体形态称号、实体图的办法与实体形态映照等。记着,这只合用于保留变动,你仍要先以某种体例跟踪该变动。
AyendeRahien注释了它是怎样完成的:上面是用NHibernate的处置办法:session.Merge(entityFromPresentationLayer);
Frans"LLBLGen撑持相似的功效。换句话说,这是数据会见框架做的事,而非开辟职员。 谈到FransBouma,上面是他总结的一些情形,一切那些利用数据集的开辟者,怎样确信EF是准确体例呢?数据集在甚么时分办理过这个成绩的呢,从一入手下手吗?更别提是否是那些大批合作性的O/R映照器框架?我想中心的成绩是计划框架的毛病,从框架开辟职员的角度来看:在你编写框架时,有两种“准确点”——来自框架开辟者的概念(PointOfView,POV)和来自框架用户的概念。中心的毛病是假定这两种“准确点”实践上是一样的,更糟的是:假定框架开辟者关于“准确点”的看法,便是框架用户所想。 检察英文原文:NoChangeTrackingforADO.NETEntityFramework2010
译者简介:王波仓促IT过客,涉足于.net编程手艺,常驻于51cto论坛.net版块,专心研讨和译书,现与朋友共译《C#3.0揭秘》,亦分享心得于博客。
本文出自:http://www.infoq.com/cn/news/2008/11/EF-2010-Fail
我以前很喜欢Serv-U,自从它用net网页编程重写之后我就再也没用过,实在是太慢了,我宁可用IIS搭建FTP,虽然IIS搭建FTP在权限管理上很不灵活。 |
|