通过服务或直接访问存储库？答案

【问题标题】：Access Repository through Service or directly?通过服务或直接访问存储库？
【发布时间】：2010-11-22 00:44:42
【问题描述】：

允许 ASP.NET MVC 控制器操作直接访问存储库（即使存在用于繁重工作的服务层，例如 LoginService.Authorize() ）以检索、添加或更新数据是一个好的编码标准吗？还是应该一切都通过服务，然后从那里到存储库？

【问题讨论】：

【解决方案1】：

在我看来，这取决于您的设计/架构。存储库的目的是什么？执行 CRUD 操作（创建、读取、更新和删除）。

如果您在经典的三层架构中使用贫血域模型，则应用于模型的所有逻辑都在服务中完成。在这种情况下，选择很明显：您不应该直接调用存储库。为什么？由于您的模型很愚蠢并且逻辑在服务中，您可以创建无效模型。如果您可以调用存储库，则可以在数据库中创建/更新无效模型。如果您调用服务，它应该能够在创建/更新之前更正或填充您的模型。

如果您在洋葱架构中使用富域模型，情况就不同了。由于您的模型应该始终有效（当您从构造函数或工厂创建模型时，所有验证都已执行，而当您更新模型时，它是同一件事），您可以毫无问题地直接调用存储库。在这种情况下，所有逻辑都直接存在于模型中，而服务仅用于存储不属于特定模型的逻辑。

现在的问题不是“如何使用存储库”而是“我需要什么设计/架构？”第一个问题将得到回答:-)

【讨论】：

【解决方案2】：

这真的取决于复杂性。如果您正在处理任何transcation scoping，我肯定会将其从控制器分离到您的服务层。

【讨论】：

【解决方案3】：

对于较小的应用程序/网络，我倾向于不使用服务层，因为它只是 1:1 映射存储库方法，并且我松了 KISS。但归根结底，这取决于商业模式； repository 抽象了 db 访问，而 services 封装了逻辑。

【讨论】：

【解决方案4】：

最好通过服务层（取决于您如何实现它），因为这就是它的重点 - 成为一个单一的访问点，因此您在那里执行的任何特定于业务的事情都会被表示和在所有调用者中实施。

【讨论】：