使用Entity Framework实体作为业务对象？

我正在使用Microsoft的Entity Framework O/R映射器,并使用实体类(映射到DB对象的生成的类)作为业务对象.这个可以吗？请说明你的缺点或专业人士.如何在业务层和演示文稿之间进行WCF通信,如何将这些对象作为数据成员发送？

首先,在写这篇文章的时候有11k的问题观点,我对于答案的缺乏和所有应有的尊重,答案的质量,给出一个相当直接的问题感到有些惊讶.

所以,既然我已经发布了一点点,我想解决这个问题,因为我认为它今天更适用于最近发布的Entity Framework Code-First.

"使用Entity Framework实体作为业务对象？"

在我开始之前有几点澄清:

当您说"业务对象"时,我的印象是您引用的这些对象包含规则或逻辑,例如,简单验证(即必需字段)到更复杂的逻辑(即结账处理税).

我不认为我可以回答你关于WCF的后续问题.这样做的原因很简单,因为我会客观地回答你关于EF作为商业对象的问题,然后主观地迫使我采取立场,证明我真实和客观地回答第一个问题的尝试是矛盾的.

那说,作为业务对象的问题,你的EF ...

"我正在使用Microsoft的Entity Framework O/R映射器,并使用实体类(映射到数据库对象的生成类)作为业务对象.这样可以吗？"

对不起,这里根本就没有对错的答案.这取决于您的目标是什么以及您认为最合理的设计,同时充分理解这样做的优点和缺点.

"请说明你的缺点或专业"

我很高兴你问!我很乐意回答,我的希望是,鉴于利弊,你能够做出明智的决定,你是否相信使用EF作为你的业务对象是"好的".通常情况下,我会突破利弊使其易于"消化",但是,我不认为这是合适的,因为我认为我们对这样一个非常有趣的话题也是不公正的亲爱的,我的心.

首先,让我在技术上谈一下......您可以使用EF对象作为业务对象,从技术上讲,没有任何东西可以阻止您这样做.事实上,EF Code-First(CF)允许您创建POCO并使您能够应用数据注释进行简单验证以及实现IValidatableObject以进行更复杂的验证,从而使这非常容易.很酷,嗯？

这就是讨论的核心.

EF或任何ORM旨在支持数据管理.它的主要职责是数据,因此您创建的对象是以数据为中心的.所以,如果你试图通过行为来设计你的对象,那么你手头上就会有一些难题.简而言之,这个难题被称为阻抗不匹配.想象一下; 您的应用程序中有两个必需的用例:

用于编辑用户的屏幕

用于显示用户信息的只读子集的控件

如果使用EF(任何风味)或任何ORM,您可能会倾向于使用相同的"用户"对象来处理保存用户以及提取用户拉取只读字段子集的功能.您可能出于以下几个原因之一这样做:

像许多开发人员一样,我们在教育期间将这种种子植入我们的大脑中"巩固代码"是最重要的,或者更好地称为DRY - 不要重复自己,因此你可能会看到重复的代码,例如属性,消极的背景.

ORM,例如EF 4.1,具有技术限制(以及破解解决方法),例如将多个POCO /对象映射到同一个数据库表,从而迫使您不管您的信念如何.

这是一种快速简便的方法来启动和运行应用程序

它"感觉"是正确的做法

这样做有利有弊,您可以根据自己的意见看待这种方式是积极的还是消极的.

我想如果你相信代码优于行为的规范化而不是你已经成功了.通过编写单个对象来处理该实体的数据和业务用例,您可以限制代码量,从而节省时间.

而且我想如果你相信代码的行为正常化而不是你失败了.通过节省代码,您牺牲了设计对象的责任,这可能会使管理变得困难并随后增加维护成本.

无论您的意见如何,我们都可能都同意这个业务对象承担了多重责任,并且对象的行为(而不是数据!)充其量只是次要的.其主要职责是数据管理,其次要职责是处理业务规则,既简单又复杂,涉及编辑用户和显示只读用户信息.在面向对象设计(OOD)中,如果对象的设计以其身份和行为为特征,则该对象可能是一个混淆的个体,因为它不符合OOD的定义.

从技术角度考虑的事情,每当您请求用户对象时,您都会继承大量的开销.当仅显示只读信息的子集时,这可能包括诸如所有属性和业务规则之类的内容.

那么所有这些与我是否应该使用EF来表示我的业务对象有什么关系呢？

嗯......虽然技术上可行,但是你是否应该使用EF或任何ORM代表你的业务对象,有不同的理念(一些好的,一些坏的).我给出了一个针对上述哲学核心的概要,但是Rocky Lhotka和Martin Fowler等人更详细地记录了这些概要.

你所采取的方向很可能取决于应用程序,从哲学的角度来看,可能取决于你是多少理想主义者或实用主义者.也就是说,我并不是说一个人是理想主义者或实用主义者,而是将EF用于商业对象,这只会影响你对此的看法.

在撰写本文时,微软表示,EF是为处理业务逻辑而构建的,无论对错,它们似乎都朝着这个方向发展.EF正在不断发展,并且正在取消某些技术限制,以便最终可以使用EF来满足两全其美.换句话说,最终你可以吃蛋糕并吃掉它.

希望这可以帮助.

为了回答一个关于持久性对ORM的无知是否荒谬的问题,考虑到其背后的目的是管理数据.:-)对不起,我无法抗拒!

我以这种方式使用EF,一个很好的特性是生成的实体是部分类,允许它们以一种相当受保护的方式进行扩展,以防止再生问题.

另请参阅MSDN上的此链接,该链接描述了与业务逻辑相关的EF的一些常见使用场景.

实体框架是为要用作业务对象的实体对象而设计的,但您应该记住,业务对象将与O/R技术以及EDM模型相关联.在EF 1.0中,没有任何对持久性 - 无知方案的支持,但在4.0中添加了支持.如果您不想使用任何基类,则可以实现接口.

从.NET 3.5 SP1开始,它们也应该可以作为参数并在WCF服务方法中返回类型,而无需任何其他代码.