存储库、服务层和方法放置

Question

我已经阅读了很多关于存储库模式和服务层的作用的书，我(我认为)很清楚这两者之间的区别。但是现在有一个简单的问题让我挠头了一段时间。

我知道数据访问层如何负责...访问数据，因此典型的存储库可能具有插入、更新、删除和保存(基本的 CRUD 方法)等方法。服务层包含所有业务内容、验证、发送电子邮件和所有爵士乐，我读到的一件事是，服务层不应重复存储库方法，因为此设置不会增加任何值(value)。

但我的问题是“添加”方法。假设我有一个供应商类，我想将一个特定的供应商添加到我的供应商列表中。用户通过 UI(MVC 网络应用程序)输入供应商信息，然后调用 Create Controller 方法。

现在 Controller 应该如何处理才能保留这个供应商？

• 直接存储库
• 服务层

由于纯存储库实现除了持久化实体之外不会做任何其他事情，如果我有一些验证和/或业务规则，我显然应该使用服务层。但是，如果我不这样做， Controller 是否应该直接与存储库打交道？在我看来，这似乎打破了架构的分层性质。 Controller 正在跳过服务层并与持久层对话。

假设我想安全起见并使用服务层(因为我可能有验证和其他与供应商打交道相关的东西)。我最终会得到:

• AddSupplier 方法
• 一个 UpdateSupplier 方法
• 一个 DeleteSupplier 方法

这是我一开始不想要的，因为现在我有一个与服务层和数据访问层的一对一方法映射。

所以我的问题是:(Add | Update | Delete)Supplier 方法应该放在哪里？

此外，是否可以绕过服务层并直接从 Controller 与存储层对话？

Answer 1

我认为您的问题没有一个明确的答案，因为有许多因素需要考虑(正如您所指出的，这也有点自相矛盾)。我相信最好的实现有几个重要的部分。

1. 一个非常通用的存储库，它与数据源交互并执行插入、更新、删除基本的 CRUD 方法(如您所指出的)。最佳情况下，这将以通用方式完成，以便您的交互在整个应用程序中保持一致。例如，返回单个实体的方法，如 T Single(Func<T, bool> where) .

2. 包含封装业务功能的方法的特定业务服务。这些服务是唯一允许与存储库交互的服务。除了“Hello World”样式示例之外，这些方法不会简单地添加或删除项目，但它们可能与 2 个或更多实体交互并执行复杂的业务逻辑。例如，服务方法可能是“CreateAccount”或“RemmoveBlogPost”，这无疑需要的不仅仅是简单地添加单个实体或删除一个实体。

3. “精简”和“哑巴” Controller ，它们实际上不执行任何逻辑，只是根据需要调用服务方法。 Controller 简单地使用变量并返回响应。但是，它们可能会在每个 Controller 操作中调用各种服务方法。服务方法的混合和重用导致高效和 DRY 编码实践。

当您意识到要在应用程序的另一部分执行某些方法的全部或部分时，这种方法就会显示出它的优势。例如，如果您正在构建一个博客应用程序，您可能会发现该应用程序的面向公众的一面需要一种查看单个博客文章的方式，而管理端也需要它。在这个简单的示例中，将在每个 Controller 中重复按 Id 返回博客文章，但是，如果您创建了一个名为 getBlogPostById 的服务方法，则可以在两个 Controller 中重用该逻辑。