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

Question

我一直在阅读很多关于存储库模式和服务层的角色，我（我认为）非常了解这两者之间的区别。但是现在一个简单的问题让我挠了脑袋。

我知道了数据访问层是如何负责嗯......存取数据，这样一个典型的仓库可以有这样的插入，更新，删除方法，并保存（基本CRUD方法）。服务层包含所有的业务资料，验证，发送电子邮件和所有爵士乐，我读的一件事是服务层不应该重复存储库方法，因为此设置不会增加任何价值。

但我的问题是'add'方法。假设我有一个供应商类别，我想将一个特定供应商添加到我的供应商列表中。用户通过UI（MVC Web应用程序）输入供应商信息，并调用控制器方法。

现在控制器应该怎么处理才能坚持这个供应商？

• 的仓库直接
• 服务层

由于纯仓库实现将不会做任何事情比坚持实体，如果我有一些验证和/或业务规则，我应该使用服务层明显。但是，如果我不应该控制器直接处理存储库？在我看来，这似乎打破了建筑的分层性质。控制器正在跳过服务层并与持久层通话。

比方说，我想在安全方面和使用的服务层（因为我有可能验证以及涉及到与供应商其他的东西）。我将结束：

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

这是我没有在第一时间想，因为我现在有什么与服务层和数据访问层进行1：1映射。

所以，我对你的问题是：在什么地方（加入|更新|删除）供应商的方法应该去？

而且，是OK绕过服务层和直接对话，从控制器存储库层？

Answer 1

我不认为这是一个明确的回答你的问题，因为有很多因素需要考虑（这也是一个很矛盾的，你所指出的）。我相信最好的实现有一些重要的部分。

1. 一个非常通用的存储库，它与数据源进行交互和执行插入，更新，删除的基本CRUD方法（如你指出）。理想情况下，这将以通用的方式完成，因此您的应用程序之间的交互是一致的。例如，返回像T Single(Func<T, bool> where)这样的单个实体的方法。包含其中封装业务功能的方法

2. 具体业务服务。这些服务是唯一允许与Repository进行交互的服务。除了'Hello World'风格的例子，这些方法不会简单地添加或删除一个项目，但它们可能与2个或更多实体交互并执行复杂的业务逻辑。例如，服务方法可能是'CreateAccount'或'RemmoveBlogPost'，毫无疑问，这需要的不仅仅是添加一个实体或删除一个实体。

3. 'Thin'和'Dumb'控制器几乎不执行逻辑，只是根据需要调用服务方法。控制器只消耗变量并返回响应。但是，他们可能会在每个控制器操作中调用各种服务方法。服务方法的混合和重用将导致高效的DRY编码实践。

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