实体框架 4 代码优先：业务方法答案

【问题标题】：Entities Framework 4 Code First: Business Methods实体框架 4 代码优先：业务方法
【发布时间】：2011-04-26 01:46:43
【问题描述】：

在使用 EF4 代码优先 POCO 时，谁能告诉我在哪里放置我的业务方法的最佳位置？他们应该参加 POCO 课程吗？例如

public class customer
    public property Id as int32
    public property Name as string
    public property Archived as boolean

    public sub MarkAsArchived
       me.Archived = true 
    end sub

    public function EmailAllInvoices as boolean
        ...
    end function
end class

或者 POCO 类是否应该尽可能干净，并为业务逻辑使用单独的类，该类在构造函数中接受客户 POCO 的实例以进行处理？

谢谢。

【问题讨论】：

标签： asp.net entity-framework orm poco

【解决方案1】：

@Ladislav Mrnka 是对的，这取决于您的架构。

您的业务规则有多复杂？他们可能经常改变吗？哪些客户端会使用您的模型，只是您自己的网站，还是您要公开 API、OData 等？

所有需要回答的问题。

就个人而言，我们有简单的业务规则和相当简单的架构。

因此，我在服务层中进行所有验证，并为我的 POCO 创建部分类以促进业务规则，并抛出自定义异常。

例如

public void Add(Order order)
{
   try
   {
      order.Validate(); // method in Order.cs partial class
      repository.Add(order);
   }
   catch (InvalidOrderOperationException exc) // custom exc
   {
      // do something
   }
}

正如我所说 - 取决于您的架构。

如果您有非常复杂的业务规则，请考虑使用规范模式。

“DDD-上帝”（Martin Fowler）对此有很好的评论here。

【讨论】：

我希望有一个可以在我们所有项目中使用的一体化实现，无论大小。
@Jamie Carruthers - 没那么简单，您必须对整体架构有所了解。它将共享哪些“项目”，您希望如何通过已编译的 DLL 将其发布到这些项目，或者您打算通过 WCF、Web API 公开操作？这里的问题是 POCO（如果要使用 WCF，则需要自跟踪实体）。我们真的需要更多关于这些项目的信息。

【解决方案2】：

这绝对取决于您的业务层的“架构”。您可以使用 POCO 作为数据传输对象，并拥有一些处理业务操作的上层业务层类——基本上我们可以谈论事务脚本模式。或者您可以将方法放置到您的 POCO 对象中并将它们“提升”为域对象。然后您的业务逻辑将位于您的域对象和域服务中（某些业务逻辑功能适用于多个域对象，因此应将其放置在单独的类中）。这被称为领域驱动设计（但它提出了更多与架构相关的想法）。

【讨论】：