Controller是否需要直接调用存储库，还是应该始终通过服务层运行？或者还有其他选择吗？
答案 0 :(得分：11)
如果您有一个服务层，并且您正在以一种将业务逻辑从存储库中抽象出来的方式使用它（就像您应该使用服务层那样）那么不，您的控制器应该只调用服务方法。然后，服务层将成为与repo的耦合。
进一步对Mayo的回答：模型是将在整个应用程序（repo，service和UI / controllers）中传递的数据类，因此UI / web层应该像其他层一样“操作”它们。 / p>
我认为如果您在Fowler's definition和modern aspnet mvc adaptions的上下文中实现服务层，那么您应该将控制器操作设计为非常小且轻量级的方法，来自服务层的“多肉”业务逻辑。
编辑：我想我不清楚：我不是说拥有服务层是唯一的选择，只是试图回答部分相关问题对于执行使用服务图层的情况。同意，服务层并不总是必要的，特别是对于较小的项目。
答案 1 :(得分：8)
您并不总是需要服务层 - 在简单的情况下，它只是过度设计解决方案。控制器调用存储库很好。但是，如果你看到你的控制器膨胀了逻辑，或者你在控制器动作中重复自己，那么看看在控制器和存储库之间放置一个服务，并将一些逻辑从控制器移到服务层。
答案 2 :(得分：3)
我同意@ Sosh关于过度工程的观点。但是我发现让控制器通过服务可以获得一个很大的好处，因为当需要通过SOAP / REST重用该服务时，您的重构工作非常少。请记住，这违反了YAGNI并且正在考虑（在某种程度上）。
但是再一次 - 在阅读了杰弗里·巴勒莫的最新着作 - MVC In Action后，他有一个控制器，直接与存储库进行零逻辑对话，它运行得很好。
答案 3 :(得分：0)
我一直在使用的所有示例似乎都表明控制器应该在模型上运行。
也就是说，我听过一些作者建议该模型由从业务逻辑到数据存储库的所有内容组成（而不是许多人认为是模型的业务对象类）。
就个人而言，我会尝试通过让控制器对存储库运行的类进行操作来保持其清洁/一致 - 但我认为没有一个强硬/快速的规则来反对它。
答案 4 :(得分：0)
服务层基本上是您的业务逻辑/业务模型的API。例如，您可能有一些方法可以获得“最佳客户”。然后，服务层执行它需要做的事情来查询存储库，执行它需要做的任何逻辑等，并返回客户。在这种情况下，您应该始终浏览服务层。
有时候，您只是检索可能位于视图模型中的对象，而不是业务模型中的对象。当然，你可以在服务层中的存储库周围添加一个包装器，但是你可能会面临服务层的混乱风险并填充无意义的东西。在这样的情况下，我认为直接进入存储库没有坏处。
答案 5 :(得分：-1)
控制器解释用户输入并准备供View使用的模型，因为我已经了解它。有些人真的很想从模型中删除每一点逻辑，但我不是那个肛门。
最佳选择IMHO是使用DI从控制器内访问您的存储库。