存储库/服务模式和数据一致性答案

【问题标题】：Repository / services pattern and data consistency存储库/服务模式和数据一致性
【发布时间】：2012-05-07 14:01:40
【问题描述】：

在使用存储库和服务模式的应用程序中，如何确保始终调用服务层而不是直接调用存储库？

例子：

class OrderRepository
{
    void CreateOrder(Order o)
    ...
}

class OrderService
{
    void CreateOrder(Order o)
    {
        //make some business logic tests
        ... 

        //call repository
        _orderRepository.CreateOrder(o);
    }
}

我看到两个问题：

程序员可以直接调用存储库，因为它不知道服务的存在（有时它不像本示例中那样简单（1 个服务 = 1 个具有相同方法名称的存储库）。有些应用程序不知道非常有据可查。否则赶时间的人可能会忘记检查是否存在相应的服务（错误）。
完全不同：很久以前，有人创建了一些直接使用订单存储库的视图 + 控制器。那时不需要做一些业务逻辑检查或额外的操作，只有订单库存在（因为那里根本不需要）。如果以后在创建订单时需要一些额外的操作，就会创建一个服务。问题是所有调用旧存储库的控制器都需要更改。存储库原则/想法（以及分层代码）不应该使各个部分相互独立吗？

【问题讨论】：

"...应该让各个部分相互独立？"这是一种误解。它旨在使职责彼此独立。 OrderRepository 仍然负责从数据库中获取数据并将数据保存到数据库中，OrderService 负责应用管理订单的逻辑。尝试通过改进方法名称来使这些职责更加清晰。 SaveOrder 而不是 CreateOrder for OrderRepository 是一种方法。

标签： c# model-view-controller oop repository-pattern

【解决方案1】：

您可以构建您的解决方案，以便所有存储库和服务都在各自的项目中，例如。 Repositories 和 Services。

应该引用Repositories 的唯一项目是Services。这样，其他项目将无法访问存储库。当然，没有什么可以阻止开发人员将存储库项目包含到控制器项目中，但希望此时他们会问自己为什么一开始没有包含它。

【讨论】：

换句话说：这是否意味着我必须从一开始就为每个可能的存储库（以及内部的每个方法）创建一个服务？如果我有很多存储库和方法，最初创建和维护是否需要付出巨大的努力？（或者我不明白你的提议）
我可能没听懂你的问题。我所描述的是，如果从不直接调用存储库，那么是的，总会有一个服务会调用一个（或多个）存储库。如果可以直接调用某些存储库，那么这将不起作用。至于工作量，如果您只想公开一个简单的存储库方法，则涉及更多的管道，但我认为这是值得的。

【解决方案2】：

Static analysis 工具可以在这方面提供帮助。

nDepend 是一个商业工具，可以集成到您的构建过程中并在这种情况下出错（任何非服务类直接调用存储库类）。

【讨论】：