具有业务逻辑的存储库模式答案

【问题标题】：Repository pattern with business logic具有业务逻辑的存储库模式
【发布时间】：2014-06-11 11:50:56
【问题描述】：

我只是打算编写基于 DDD 的演示应用程序。我的存储库使用实体框架 ORM，一切都很好。 MVC 和 Windows 窗体应用程序调用存储库方法并且有效。但是如果我决定用 Dapper 或 NHibernate 替换 Entity Framework 或者我的数据来自 Web 服务怎么办？我知道我需要重写存储库实现，但是我的业务逻辑是什么。业务逻辑现在放置在存储库中。一些示例在控制器中有业务逻辑，但我有多个客户端。我需要在存储库上方放置一些层吗？在 DDD 的概念中，该层的名称是什么。

【问题讨论】：

如果您的业务逻辑在存储库中，则您没有使用 DDD。事实上，你离 DDD 有多远，你可以来。购买 DDD 书，阅读它，然后提出一个新问题。或者干脆从您的问题中删除 DDD 引用。
业务/领域逻辑应该在你的领域层（领域实体或服务）；和应用层中的应用/业务逻辑。您的存储库应该不了解任何领域或业务逻辑，并专注于数据逻辑。
域层？业务层？
更多见解：ludwigstuyck.wordpress.com/2013/03/05/…
@L-Three：可以改进该系列文章中的存储库实现以降低复杂性（通用存储库在开始时似乎是个好主意，但与使用 ORM 接口相比，它们没有任何好处直接地）。要么正确实现该模式，要么干脆不使用它。

标签： c# repository-pattern

【解决方案1】：

我知道我需要重写存储库实现，但是我的业务逻辑是什么。业务逻辑现在放置在存储库中。

这让我很担心。如果您的业务逻辑放置在您的存储库中，那么您根本就没有在实践领域驱动设计。在 DDD 中，您的业务逻辑位于您的域实体中。存储库的目的只是返回填充的域对象。域对象不应该知道它们是如何保存的（无论是在数据库中、xml 文件中，还是只是动态创建的）。

领域驱动设计的全部目的是让您摆脱对任何特定基础架构的束缚。无论您使用的是实体框架还是 Dapper，您的域对象都应该能够工作。

【讨论】：

【解决方案2】：

通常，您可以创建一组代表您的域模型的类。然后，您将拥有一组用于存储库的类，这些类将使用域模型类进行读/写。这使您可以独立地更改一个。

例如领域模型：

class Vehicle
{
    string id; // or you can use an appropriate key
    int noOfWheels;
    int topSpeed;
    // etc.
}

class Car : Vehicle
{
    int passengerCapacity;
    int trunkCapacity;
    // etc.
    string Serialize();
    void Deserialize(string representation);
}

还有你的存储库：

class VehicleRepository
{
    void Store(Vehicle v);
    Vehicle GetVehicle(string id);
    void Delete(string id);
    // etc.
}

为了代码简洁，我避免添加接口。但是，一般来说，这种结构将允许您修改域对象，而不管存储库如何，反之亦然。因此，您可以拥有一个存储库，通过序列化/反序列化对象将您的对象放入 NOSQL 存储（或用于本地测试的文件系统），但另一个存储库将从 SQL 存储中 CRUD 对象。

我已经在对象上包含了序列化/反序列化方法，这在大多数情况下都有效。但是，有时必须将其分离到单独的类中并隐藏在存储库后面，以便使用物理存储介质进行版本控制（即您的物理表示可能会改变，但您的域对象不应受到影响，反之亦然）。

【讨论】：

【解决方案3】：

我需要在 Repository 上方放置一些层吗？

是的。存储库的目标是简单地从域层删除有关数据如何持久化的知识。这是为了强制分离关注点并保持域“纯”。存储库通过为您的域对象提供抽象来实现这一点，从而将它们呈现为内存中的集合。

但是请注意，存储库的接口应该在域中定义，因为存储库在那里为域提供服务，并且只有域可以定义其与数据的合同。

在 DDD 概念中该层的名称是什么？

存储库属于基础架构层。上面的层是领域层，所有业务逻辑都在其中。

【讨论】：