Danny Simmons——一个在 ADO.NET 实体框架(Entity Framework,EF)项目中的微软开发人员,他最近发表了一个对实体框架和其他数据访问解决方案比较的博客帖子。在和传统的 ADO.NET 及 LINQ to SQL 比较之后,Danny 又把实体框架和 nHibernate 进行比较,这就引起了其他开发人员的反对。下面是 Danny 的帖子的摘录:
在 EF 和 nHibernate 之间最大的不同是,实体数据模型(Entity Data Model,EDM),以及我们基于这个东西构建的需要长久运行的数据平台。EF 通过了特别的构造,将查询 / 形成结果的映射过程,与构建对象和变更跟踪分离开来。这种方式让创建概念模型变得更为容易,而概念模型使你可以考虑如何实现数据,以便随后能在其他很多包含了这些构建对象的服务中重用。长期以来,我们把 EDM 这样的思想融入到多个其他微软产品中,以至于假如你拥有一个实体数据模型,你可以基于这个模型自动创建面向 REST 的 Web Service(ADO.NET Data Service,即 Astoria);可以基于这个模型编写报表(Reporting Services);可以在服务器和脱机客户端存储库中同步数据,这些数据可以作为实体进行原子性地移动,就算这些实体是从服务器上的多个数据库表中抽取而来;可以从实体感知的构建部件中创建工作流;等等,等等……所以,所谓的不同点不是 EF 比 Nhibernate 能支持更复杂的映射功能或其他类似的东西,而是在于——EF 不仅仅是一个 ORM,它是在基于实体理念的数据平台中庞大愿景中的第一步。
作为回应,Frans Bouma, LLBLGen Pro 的主创人员,一个微软 MVP,在它的帖子中写到:
我不同意这种说法:一个像 Danny Simmons 这样工作于实体框架中如此久的人,这样的人怎么能忽略这样一个事实——任何 O/R Mapper 都是针对实体理念的。在他最后一句话中所描述的东西,实际上是一个单一目的的 O/R Mapper:就是让开发人员能在 OO 语言中使用实体实例,并把这些实例保存到如关系数据库这样的非 OO 环境中,反之亦然。假如所有的东西就是抽象的实体模型和它的投射,那么更大的愿景是什么呢?也许工具?它让开发人员创建这些投射和在应用程序代码中调用 O/R Mapper 服务根据容易。
Jeremy D. Miller,一个.NET 开发人员和构架师,在他的博客中说到 Danny Simmons:
他在比较 NHibernate 和实体框架过程中遗漏了一个重要的事实。实体框架对你的应用程序具有很强的入侵性,而 Nhibernate 没有。NHibernate 让我能使用 POCO 的方式来对业务过程进行建模而无需知晓数据库。而,实体框架却要我把 EF 的基础结构直接加入到我的业务对象中。
Danny Simmons 提到的为其他目的(如报表)而使用 EDM 的好处,Greg Young——一个微软的 MVP,在他的博客上对其进行了评论
一个单一的模型不可能适应你的应用程序里包括事务行为、搜索和报表在内的所有方面……可以举出很多这样的内容来。如果你基于你的事务模型来创建报表,那么你就会遇到麻烦!
Jimmy Bogard,一个 Headspring Systems 的高级顾问,也在他的博客中回应到:
我认为把数据模型共享给你边界外的任何人,是错误的(参看 Evans,Domain-Driven Design)。把概念模型或 EDM 或其它我们以任何名字称呼它的东西共享出来也是错误的。
我从来不把域对象直接通过服务暴露出来。这是对我尽量创建的封装的一种侵害。
如果任何人想要一个 SSRS【译者注:SQL Server Reporting Service】,那么我会给他们一个单独的报表数据库——为报表所需而定制的。我不希望报表的关注点影响了我们的事务关注点。一个映射层不能解决这样的问题,但类似 SSIS【译者注:SQL Server Integration Service】这样的产品却可以。你想要报表?好,这里有你需要的只读视图,每小时、5 分钟、每天或随时进行更新。
所以,现在的问题是:ADO.NET 实体框架是否已经不仅仅是一个 O/R Mapper 了,以及它如何和 nHibernate 进行比较?很多人倾向于认为 EF 是一个简单的 O/R Mapper,并认为它相对于 nHibernate 而言缺乏很多特性。另外一方面,Danny Simmons 说微软刚刚开始开发 EF,他们的计划是未来要超越当前的 O/R 映射功能。
查看英文原文: The ADO.NET Entity Framework Sparks a Debaterks a Debate
评论