服务层和仓储

Question

我已经使用MVC框架有一段时间了，我非常喜欢它将关注点分离的功能。但是我养成了一个坏习惯，让控制器做了很多工作。所以我真的需要一些建议。

当我第一次使用MVC时，我经常让控制器对数据库操作后的模型进行操作。我知道这是不好的，所以我将这项工作移至模型中。然而，我对此并不满意，因为我希望我的模型非常简洁。

我阅读了一些资料，发现人们通过引入服务层来保持控制器和模型的简洁性，我很喜欢这个想法。

我只是想了解服务层和仓储库应该如何协同工作。以下是我的假设，请告诉我这是否是一种良好的工作方式？

1. 如果数据不需要进行任何操作，则控制器可以直接调用仓储库，因此不需要涉及服务层。
2. 如果需要对数据进行任何操作（业务逻辑），则应在服务层中执行，并且控制器将根据需要简单地调用服务层。
3. 一旦服务完成其业务逻辑，就会根据需要使用仓储库（如果需要持久化数据）。
4. 最好将模型保持简洁，仅充当DTO（数据传输对象）。
5. 使用MonoRail验证属性可以在模型中进行数据验证。我明白没有人喜欢在模型中添加许多属性，但这是另一个讨论。我喜欢MonoRail的验证属性之所以有益，是因为它可以自动验证jQuery在用户界面上的内容。

我试图将所有代码都转变成单一责任原则，因此试图整理我的编码实践。

谢谢

- johnners

Answer 1

首先，不存在适用于每种情况的一套规则。您如何建模应用程序取决于项目的类型和复杂性。话虽如此，这里有一些想法：

1. 从控制器调用存储库没有问题。只要确保控制器不包含业务逻辑即可。
2. 服务负责（某些）业务逻辑，并使用其他服务来实现。存储库是某种类型的服务，从服务中调用它没有问题。
3. 模型应该包含业务逻辑，实际上您应该始终尝试首先将其放入模型中。如果需要外部数据来执行该业务逻辑（来自另一个模型或存储库），则应创建一个服务。
4. 在模型中进行验证没有问题。使用属性与否是品味问题（如果您喜欢它，那么就是好的）。如果验证过程变得太复杂，请将其移到模型之外（创建一组外部规则）。

最重要的是，做正确的事情（通常就是正确答案）。

- gcores

---

我唯一担心将业务逻辑放在模型中的问题是，当通过PropertyBag（或其他方式）将模型集合传递给UI时，您可能会向UI开放业务逻辑。 - John Polling

我同意你的评论，只是感觉过多的业务逻辑应该存储在独立的服务层中。尽可能保持模型、视图和控制器的简洁。 - StevenMcD

Answer 2

这个视频提供了关于如何组织你的asp.net MVC解决方案、处理关注点分离和更好的可测试性的有价值见解。希望它也能帮助其他人。我从中学到了一些有用的东西。

- Mandeep Janjua

---

这是一段非常有帮助的视频。相关的源代码也可以在这里找到：https://bitbucket.org/ardalis/guestbook/src - Joseph Woodward

Answer 3

Ian Cooper刚刚写了一篇名为“The Fat Controller”的博客，讨论了这个主题。

（注：该博客是关于IT技术中的控制器模式）

- Macka