MVC DDD：可以将存储库与控制器中的服务一起使用吗？

大多数时候，在服务代码中我会有这样的内容：

public SomeService : ISomeService
{
    ISomeRepository someRepository;
    public Do(int id)
    {
        someRepository.Do(id);
    }
}

所以这有点多余

所以我开始直接在控制器中使用存储库

这个可以吗 ？有没有一些架构是这样做的？

您将失去在两者之间保留业务逻辑的能力。

我不同意这一点。

如果业务逻辑位于它应该在的位置 - 在域模型中，那么在控制器中调用存储库（或者更好 - 使用模型绑定器）来获取聚合根并调用它的方法对我来说似乎完全没问题。

当涉及太多技术细节而导致控制器混乱时，应该使用应用程序服务。

我最近看到几个人提到使用模型绑定器来调用存储库。这个疯狂的想法从何而来？

我相信我们在这里讨论的是两件不同的事情。我怀疑你的“模型绑定器”意味着同时使用模型作为视图模型，并将 UI 中的更改值直接绑定回它（这本身并不是一件坏事，在某些情况下我会走那条路）。

我的“模型绑定器”是一个实现“模型绑定器'，它在构造函数中获取存储库（它被注入，因此 - 如果我们需要使用一些基本组合进行缓存，则可以对其进行扩展）并在调用操作之前使用它来检索聚合根并替换int id or Guid id or string slug or whatever具有真实域对象的动作参数。将其与输入视图模型参数相结合可以让我们编写更少的代码。像这样的东西：

public ActionResult ChangeCustomerAddress
 (Customer c, ChangeCustomerAddressInput inp){
  c.ChangeCustomerAddress(inp.NewAddress);
  return RedirectToAction("Details", new{inp.Id});
}

在我的实际代码中，它有点复杂，因为它包括 ModelState 验证和一些可能从域模型内部抛出的异常处理（提取到控制器扩展方法中以供重用）。但仅此而已。到目前为止 - 最长的控制器操作约为 10 行。

您可以看到工作实现（非常复杂并且（对我来说）不必要的复杂）here.

您只是使用 Linq To Sql 执行 CRUD 应用程序还是尝试使用真正的域逻辑？

正如你（希望）看到的，这种方法实际上几乎迫使我们走向基于任务应用程序而不是基于 CRUD 的应用程序。

通过在服务层中进行所有数据访问并使用 IOC，您可以获得 AOP 的许多好处，例如不可见的缓存、事务管理以及组件的轻松组合，这是我无法想象通过模型绑定程序获得的。

...并拥有新的抽象层invites我们将基础设施与领域逻辑混合在一起，并失去领域模型的隔离。

请赐教。

我不确定我是否做到了。我不认为我自己开悟了。 :)

Here是我当前的模型活页夹基类。Here's我当前项目中的控制器操作之一。和here's“缺乏”业务逻辑。