它是一个很好的编码标准，允许ASP.NET MVC控制器操作直接访问存储库（即使服务层存在繁重的工作，例如LoginService.Authorize（））来检索，添加或更新数据？或所有应该通过服务，还是从那里到存储库？
答案 0 :(得分：4)
对于较小的应用程序/网站，我倾向于不使用服务层，因为它只是映射存储库方法1：1，而我松散了KISS。但最终，它取决于商业模式; repository抽象db访问，服务封装逻辑。
答案 1 :(得分：2)
最好通过服务层（取决于你如何实现它），因为这就是它的重点 - 成为一个单一的访问点，因此你在那里做的任何特定于业务的东西都被表示出来，在所有来电者中实施。
答案 2 :(得分：1)
这实际上取决于复杂性。如果您正在处理任何transcation scoping，我肯定会将其与控制器分离到您的服务层。
答案 3 :(得分：0)
在我看来，这取决于你的设计/架构。存储库的目的是什么？执行 CRUD 操作（创建，读取，更新和删除）。
如果您在经典的三层架构中使用贫血域模型，则应用于模型的所有逻辑都在服务中进行。 在这种情况下，选择是显而易见的：您不应该直接调用存储库。 为什么？由于您的模型很愚蠢，逻辑在服务中，您可能会创建无效模型。如果可以调用存储库，则可以在数据库中创建/更新无效模型。如果您调用服务，它应该能够在创建/更新之前更正或填充您的模型。
如果您在洋葱架构中使用富域模型，则会有所不同。由于你的模型应该始终有效（当你从构造函数或工厂创建一个所有验证时都已执行，当你更新一个它同样的东西时）你可以毫无问题直接调用存储库。 在这种情况下，所有逻辑都直接在模型中，服务仅用于存储特定于某个模型的逻辑。
现在的问题不是＆＃34;如何使用存储库＆＃34;但是＆＃34;我需要什么设计/架构？＆＃34;第一个问题将得到回答： - ）