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

.net architecture entity-framework

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

一般承认的答案

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

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


热门答案

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

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

“使用Entity Framework实体作为业务对象?”

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

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

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

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

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

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

“请说明你的缺点或优点”

我很高兴你问!我很乐意回答,我希望这里有一个优点和缺点,你能够做出明智的决定,你是否相信使用EF作为你的业务对象是“OK”。通常情况下,我会突破优点和缺点,使其易于“消化”,但是,我不认为这是合适的,因为我认为我们对这样一个非常有趣的话题不公正这也是我的心脏附近和亲爱的。

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

这就是讨论的核心。

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

  1. 用于编辑用户的屏幕
  2. 用于显示用户信息的只读子集的控件

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

  1. 像许多开发人员一样,我们在教育过程中将这种种子植入我们的大脑中 - “巩固代码”至关重要,或者更好地称为DRY - 不要重复自己,因此您可能会看到重复的代码,例如作为属性,在负面背景下。
  2. ORM,例如EF 4.1,具有技术限制(以及破解解决方法),例如将多个POCO /对象映射到同一个数据库表,从而迫使您不管您的信念如何。
  3. 这是一种快速简便的方法来启动和运行应用程序
  4. 它“感觉”是正确的做法

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

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

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

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

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

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

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

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

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

希望这可以帮助。

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




许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因