业务逻辑和业务实体有什么区别？答案

【问题标题】：What are the differences between business logic and business entities?业务逻辑和业务实体有什么区别？
【发布时间】：2012-09-23 06:45:41
【问题描述】：

我在每个项目中的基本解决方案结构是：

Dal - 数据访问层
业务逻辑分为两部分，一是业务实体，二是业务逻辑

所以在我目前的实践中，我的实体只包括数据成员和属性，而不包括 CRUD 操作。将 CRUD 操作放在 Entity 中总是感觉不对。我的想法是..

哪个实体删除自己没问题？
可以添加哪个实体自己去数据库？

所以我将 CRUD 操作移到了另一个库（类），它代表了我的业务逻辑。

例如，假设我们有一个 foo 实体

public class Foo
{
    //Data Members
    private int _id;
    private string _Name;

    //Properties
    public int ID { get; set; }
    public string Name { get; set; }
}

所以对于这个实体，我将创建一个包含所有 CRUD 操作的 FooLogic 库（类），例如：

添加新实体
删除实体
获取实体列表
更新实体等等……

所以我要问的是：

不将CRUD操作放在实体对象中是正确的做法吗？
如果是这样，我当然应该在“打印详细信息”旁边的实体中放入什么方法
每个重要实体都有业务逻辑库（类）可以吗？

【问题讨论】：

标签： asp.net projects-and-solutions crud

【解决方案1】：

我不能说在任何情况下都是绝对正确的（因为什么都不是，但也因为我不是真正的“企业”-y 开发人员），但是...

数据库/实体操作，例如插入和更新，通常由封装每个数据库操作的 Repository 类处理。存储库方法接受或返回表示数据库记录（或记录，如果您有良好的 ORM）的实体类对象。实体对象应该是 POCO 并且不包含将自身直接绑定到数据库的逻辑 - 这允许您将默认存储库实现替换为模拟，这使得测试变得更加容易。
- 请注意，在 .NET 世界中，您的 EF DbContext 已经是一个存储库。您不需要自己重新实现存储库模式。
仅对实体对象的内存状态进行操作的访问器和修改器。这包括琐碎的属性，但也包括诸如Person.GetFullName() 之类的东西，它可以连接Person.FirstName 和Person.LastName 字段，例如。
- 因此，您的 Person 类上不会有一个名为 SendEmailTo() 的方法，因为这实际上不是对 Person 的操作，而是在您的电子邮件系统上的操作。
一般来说，没有。您的业务逻辑应该响应传入的消息（例如客户端事件或轮询计时器）而发生，并且与单纯的存储库任务不同。

以下是我实施简单 CRM 的方法（使用单个实体，Customer）：

一个实体类`DBCustomer`:

（可能由实体框架生成）表示存储在数据库中的客户。

class DBCustomer {
    public String FirstName { get; set; }
    public String LastName  { get; set; }
    public String FullName  { get { return this.FirstName + " " + this.LastName; } }
}

存储库

Entity Framework DbContext 是您的存储库对象，因此无需在此处完成任何工作。

业务逻辑

...例如 WCF 消息处理程序 - 但有时逻辑非常简单，尤其是当业务操作直接对应于数据库操作时，例如

StatusCode Customer_Add(CustomerXml newCustomerXml) {
    DBCustomer newCustomer = createNewCustomerFromXmlMessage( newCustomerXml );

    using( MyDbContext dbc = CreateDbContext() ) {
        dbc.Customers.Add( newCustomer );
        dbc.SaveChanges();
    }

    return StatusCode.Success;
}

现在您可能会注意到这里似乎有很多无用的层 - 我可以使用 CustomerXml 类（它表示反序列化的以前 XML 格式的消息），然后直接从 WCF 消息事件调用 EF 上下文方法处理程序，它适用于非常琐碎的项目，但是随着项目的增长，您会发现您需要在每一步添加自定义逻辑，突然事情变得难以管理。

因此，对于一个简单的数据驱动型网站，一个简单的“在同一层中做所有事情”的方法可以正常工作，但规范中有很多小问题的“企业”应用程序将需要这些额外的层。

【讨论】：

【解决方案2】：

关于 1,2 - 在对象持久性工具和 ORM 中有两种不同的常用方法，ActiveRecord 模式和 Repository 或 DataAdapter 模式。 ActiveRecord 是将 CRUD 和其他一些操作放在实体对象中的一种，存储库模式将实体 (DTO) 与这些实体上的操作分开。
Active Record 模式有它自己的优势（据说更简单），但我更喜欢 Repository，因为它更灵活且可测试。

3- 为每个实体创建一个项目有什么好处，我认为这不是一个好主意。

【讨论】：

一个实体类DBCustomer:

存储库

业务逻辑

一个实体类`DBCustomer`: