控制器 - 它应该直接处理服务层或存储库吗？

Question

网上有太多相互矛盾的文章。您对此有何个人看法（对于企业应用程序）.​​....

在我的C＃/ MVC应用程序中，我按照此处的建议设置了我的体系结构，减去了依赖注入和automapper：https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/

一般来说，在谈到MVC控制器时，它应该只直接处理服务层吗？或者直接处理存储库仍然是一种好习惯吗？什么可以帮助你决定？

此外，是否应在控制器级别创建UnitOfWork类，然后将其传递到Service / repo？

由于

Answer 1

嗯，工作单元，我认为没有用，因为DBContext可能是工作单元， 您也可以使用DbContext作为存储库。 我是否需要存储库和服务层，我认为其中一个就足够了，取决于项目的复杂性，服务是层，当你有更复杂的项目时。 您应该考虑如何重用代码，并保持简单，但不要创建大量的层，使用不可重用的代码

Answer 2

通常，存储库包含尽可能少的代码。我的意思是它们只包含用于插入，更新和从内部实现中删除项目的代码。它们存在是因为您想要切换DAL实现。如果要直接在控制器中使用存储库，则必须在控制器中编写域逻辑，这不是一个好习惯。控制器必须很小，只能转发对域逻辑或服务的请求。

因此，在我的想法中，最好在控制器中使用服务。

如果您在服务中实例化UOW，您将在每项服务中以新的工作单元结束。创建工程单位可能很昂贵。因此，如果您在一个控制器中需要两个或三个服务，您将在一个控制器中有两个，三个单元的工作。

因此，我认为将服务单元注入服务会更好。

我再说一遍如果你想切换DAL实现，Repository和工作单元很有用（例子可以用内存数据测试代码）。

Answer 3

就我个人而言，我觉得服务层对于任何中型到大型API都是至关重要的，并且在这个级别上你应该处理工作单元（如果你决定使用它）。您不应该在控制器级别处理存储库的原因是为了提高架构的灵活性，并防止将服务与协议或实现紧密耦合。

作为示例，假设您今天将服务公开为REST服务。明天，您可能想要使用其他协议（可能是SOAP或其他）。通过使用服务层，协议层（控制器）就会丢失，很容易被替换。

另一个鼓励服务层和依赖注入的例子是，如果在将来的某个时候，你想要改变服务的实现，你将不得不从控制器开始改变代码，而不仅仅是创建和注入你的新实施。

然而，在一天结束时，以上只是可能或可能不适用于您的项目的意见和可能的情况。您的选择应取决于您的特定项目的性质（大小，复杂性，变化的可能性......）。

Answer 4

这真的取决于你的申请。

让我举一个我将使用的架构示例。

1. MVC网站项目
2. 业务层项目
3. 持久层项目
4. 公共图层项目
5. 测试项目

1个控制器，视图，ViewModels。这是您将BL模型转换为ViewModels的地方。

2您的业务层。如果您的BL在数据库上并且您只对显示数据感兴趣，则可以省略此项。但是，如果你开始新项目，这就是BL应该是的地方。您的所有业务决策，验证等等。 此外，如果您的BL模型与您的数据库不匹配，那么您可以将数据库数据转换为BL模型

3此层​​仅用于与数据库通信。用最少的逻辑。

4共同对象。像扩展方法一样。或通过应用程序使用的其他对象这应该尽可能轻！

5这是您为应用程序编写测试的地方 - 如果您希望为每个图层创建项目，可以将其拆分为多个项目

注意：

1 - 在这里你还应该考虑一下你的View以及如何分离Controller，ViewModel和你的HTML，javascript等之间的关注......这实际上取决于你的观点的复杂性。

我建议您使用依赖注入它是一个很好的工具，特别是如果您正在构建企业应用程序。