我正在使用微软的实体框架O/R映射器，并使用实体类（映射到DB对象的生成类）作为业务对象。
这样行吗？请陈述你的利弊。在业务层和表示层之间进行WCF通信的情况下，如何将这些对象作为数据成员发送
首先，在写这篇文章的时候，有11k个问题的观点，我有点惊讶于答案的缺乏，并且恕我直言，对于一个相当直截了当的问题，答案的质量令人惊讶
所以，现在我已经讲了一点，我想解决这个问题，因为我认为它在最近发布的Entity Framework Code First中更适用
“使用实体框架实体作为
业务对象？”
在我开始之前，有几点需要澄清：
-
当你说“业务对象”时，我的印象是，你提到的这些对象包含规则或逻辑，范围从简单的验证（即必填字段）到更复杂的逻辑（即结帐时处理税务）
-
我认为我无法回答您关于WCF的后续问题。这样做的原因很简单，因为我将客观地回答您关于EF作为业务对象的问题，这将主观地迫使我采取一种与我试图真正客观地回答上述第一个问题相矛盾的立场
也就是说，关于你的EF作为业务对象的问题
“我正在使用实体框架O/R映射器
来自Microsoft并使用实体
类（生成的
映射到数据库对象）作为业务
对象。这样可以吗？”
对不起，这里没有正确或错误的答案。这取决于您的目标是什么，以及您认为什么是最合理的设计，同时充分了解这样做的优缺点
“请说明你的利弊”
我很高兴你问我！我很乐意回答，我的希望是，考虑到利弊，您能够做出明智的决定，即您是否认为将EF用于您的业务对象是“OK”的。通常情况下，我会说出利弊，让它更容易“消化”，然而，我认为这在这里并不合适，因为我认为我们会对这样一个非常有趣的话题做不公正的事情，这个话题也离我很近，也离我很近
首先，让我从技术上讲一下……您可以将EF对象用作您的业务对象—从技术上讲，没有什么可以阻止您这样做。事实上，EF Code First（CF）通过允许您创建POCO并使您能够应用数据注释进行简单验证，以及实现IValidatableObject进行更复杂的验证，使这一过程变得非常简单。很酷吧
这就是讨论的核心
EF或任何ORM都是为支持数据管理而设计的。它的主要职责是数据，因此您创建的对象是以数据为中心的。因此，如果您试图通过行为来设计对象，那么您手头有一个小难题。简而言之，这个难题叫做阻抗失配。想象一下这个；您的应用程序中有两个必需的用例：
- 编辑用户的屏幕
- 用于显示用户信息的只读子集的控件
如果使用EF（anyflavor）或任何ORM，您可能会倾向于使用相同的“User”对象来处理保存用户以及获取用户以提取只读字段子集的功能。您这样做可能是出于以下原因之一：
- 和许多开发人员一样，我们在教育过程中也在大脑中播下了这颗种子“整合代码”非常重要，或者更确切地说是“干”——不要重复自己，因此您可能会在负面环境中看待代码的重复，例如属性
- 像EF4.1这样的ORM有技术上的局限性（以及黑客的解决方法），比如将多个POCO/对象映射到同一个数据库表，从而迫使您不考虑自己的想法
- 这是启动和运行应用程序的一种快速而简单的方法
- 这“感觉”是正确的做法
这样做有好处也有坏处，你可以根据自己的观点来看待这是积极的还是消极的
我想，如果您相信规范化的代码胜过行为，那么您已经取得了巨大的成功。通过编写单个对象来处理该实体的数据和业务用例，您可以限制代码量，从而可能节省时间
我想如果你相信行为规范化胜过代码，那么你就惨败了。通过节省代码，您牺牲了设计对象的责任，这可能会使其难以管理，从而增加维护成本
不管您怎么看，我们可能都同意，这个业务对象承担了多重责任，对象的行为（而不是数据！）充其量只是次要的。其主要职责是管理数据，次要职责是处理业务规则，包括简单和；复杂，涉及编辑用户和显示只读用户信息。在面向对象设计（OOD）中，如果一个对象的设计以其身份和行为为特征，那么这个对象可能是一个混乱的个体，因为它不符合OOD的定义
从技术角度考虑，任何时候请求用户对象都要继承大量的开销。当仅显示只读信息的子集时，这可能包括诸如所有属性和业务规则之类的内容
那么，所有这些与我是否应该使用EF来表示我的业务对象有什么关系呢
嗯……虽然在技术上是可能的，但对于是否应该使用EF或任何ORM来表示您的业务对象，存在不同的理念（一些好的，一些坏的）。我给出了一个针对上述哲学核心的概要，但洛基·洛特卡和马丁·福勒等个人对其进行了更详细的记录
你选择的方向很可能取决于应用程序，从哲学的角度来看，可能取决于你是一个多么理想主义者或实用主义者。这就是说，我并不是说一个人是理想主义者或实用主义者与是否将EF用于业务对象相关——这只会影响你对此的看法
在撰写本文时，微软的迹象表明，EF是为处理业务逻辑而构建的，无论是对是错，它们似乎更倾向于这个方向。EF不断发展，某些技术限制正在被取消，因此EF最终可能被用于满足两个世界的最佳需求。换句话说，最终你可能会有你的蛋糕，也可以吃它
希望这有帮助
考虑到ORM背后的目的是管理数据，请回答一个关于ORM的持久性无知是否荒谬的问题。：-）对不起，我无法抗拒