服务层和存储库

Question

我一直在使用MVC框架一会儿，我真的很喜欢这些问题是如何分离出来的。我已经陷入让控制器做很多工作的坏习惯。所以我真的在寻找一些建议。

当我第一次开始使用MVC时，我经常让控制器在数据库工作完成后对模型进行操作。我知道这很糟糕，所以搬到模型中。不过，我并不满意，因为我希望我的模型能够很好地学习。

我已经做了一些阅读，我发现人们通过拥有一个服务层保持他们的控制器和模型精益，我喜欢它的外观。

我只是想了解服务层和存储库应该如何一起工作。这是我的假设，你能否让我知道这是否是一种好的工作方式？

1. 控制器可以直接调用库中，如果没有操作需要对数据和作为这样一个服务层完成并不需要涉足
2. 一旦任何工作需要做数据（业务逻辑），那么这应该在服务层中完成，并且控制器将根据需要对服务层进行简单调用
3. 一旦服务完成它的业务逻辑，它就会根据需要使用存储库（如果数据需要坚持）。
4. 理想情况下，模型应该保持精益，理想情况下只能作为DTO使用
5. 验证数据将在模型内完成（使用MonoRail验证属性）。我很欣赏，即使人们喜欢用很多属性来污染他们的模型，但这是一个不同的讨论。我喜欢MonoRail的验证属性在UI中自动jQuery验证的好处。

我想把我所有的代码都转到单责任原则，因此试图理清我的编码实践。

谢谢

Answer 1

首先，没有一套规则在任何情况下都能正常工作。你如何建模你的应用程序很大程度上取决于项目的类型和复杂性。话虽如此，这里有一些想法：

1. 从控制器调用存储库没有错。只要确保控制器不包含业务逻辑。
2. 该服务负责（一些）业务逻辑并使用其他服务来执行此操作。存储库是一种服务，从服务调用它没有任何问题。
3. 模型应该包含业务逻辑，实际上你应该总是试着把它放在模型中。如果您需要外部数据来执行该业务逻辑（从另一个模型或存储库），那么您应该创建一个服务。
4. 模型验证没有问题。使用属性与否是品味的问题（如果你喜欢它，那就很好）。如果模型过于复杂（创建一组外部规则），请在模型外部移动验证。

最重要的是，做什么感觉是正确的（这通常是正确的答案）。

Answer 2

伊恩·库珀刚刚写了眼前这个主题叫做The Fat Controller博客文章。

Answer 3

This视频提供了很大的洞察到如何组织你的asp.net MVC解决方案，并关注解决分离，更好的可测试性。希望它能帮助别人。我从中学到了一些好东西。