服务层和存储库

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

当我第一次开始使用MVC时，我经常让控制器在数据库工作完成后对模型进行操作。我知道这是不好的，所以搬到模型。然而，我不满意，因为我希望我的模型是非常有学问的。

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

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

如果不需要对数据进行操作，则控制器可以直接调用存储库，因此不需要涉及服务层
一旦任何工作需要完成数据（业务逻辑），那么这应该在服务层完成，控制器将根据需要简单地调用服务层
一旦服务完成了业务逻辑，它就会根据需要使用存储库（如果数据需要保存）。
理想情况下，模型应该保持精益，理想情况下只是DTO的行为
数据validation将在模型中完成（使用MonoRailvalidation属性）。我很欣赏，甚至不喜欢用很多属性来污染他们的模型，但这是一个不同的讨论。我喜欢用户界面中自动jQueryvalidation的MonoRailvalidation属性的好处。

我试图把我所有的代码都转化为单一责任原则，因此试图理清我的编码习惯。

谢谢

首先，在任何情况下都没有一套规则可行。你如何build模你的应用程序很大程度上取决于项目的types和复杂性。话虽如此，这里有一些想法：

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

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

Ian Cooper刚才写了一篇名为“肥胖控制器”的博客文章。

这个video给出了如何组织你的asp.net MVC解决scheme和解决问题的分离和更好的可testing性的伟大的洞察力。希望它会帮助别人。我从中学到了一些好东西。