Asp.net mvc CQR-Are接口和；读模型是否需要依赖注入？

我正在实现一种CQR形式，它使用单个数据存储，但使用单独的查询和命令模型。对于命令端，我正在实现DDD，包括存储库、IoC和依赖注入。对于查询端，我使用前面描述的Finder模式。基本上，finder类似于存储库，但只使用Find方法

因此，在我的读取端应用程序中，在DAL中，我使用ADO.net和原始SQL进行查询。Net的东西都被抽象成一个很好的助手类，这样我的Finder类就可以简单地将查询传递给ADO助手，ADO助手返回通用数据对象，Finder/mapper类将这些对象转换为读取模型

目前，Finder方法（如我的命令存储库）是通过注入我的控制器的接口访问的，但我想知道接口DI和IoC对于查询端来说是否过于苛刻，因为我读到的关于CQRS读取端的所有内容都建议使用“瘦数据层”

为什么不直接访问我的查找程序？我理解接口和DI的参数。即关注点和可测试性的分离。在SOC的例子中，我的DAL已经通过使用mapper类和将ADO.net的东西放在helper类中分离出了特定于数据库的逻辑。就测试而言，根据单元测试，读取模型不是必要的

总之，对于read模型，我可以这样做：

 public class PersonController : Controller
 {
   public ActionResult Details(int id)
   {

        var person = new Person();
        person = PersonFinder.GetByID(id);

       // TODO: Map person to viewmodel


        return this.View(viewmodel);
    }

 }

与此相反：

 public class PersonController : Controller
 {

    private IPersonFinder _person;

    public PersonController(IPersonFinder person)
    {
        _person = person;
    }

   public ActionResult Details(int id)
   {
       Person person = _person.GetByID(id);

       // TODO: Map person to viewmodel


        return this.View(viewmodel);
    }

 }

您是否同时使用IoC和DI？真是个混蛋！无论如何，第二个版本更好，因为它不依赖于静态类。使用静态会打开潘多拉的盒子，不要这样做，因为使用静态是不好的

使用静态类确实没有任何好处，而且一旦您已经使用了DI容器，就不会有额外的成本。您直接使用查找器，但让DI容器实例化一个查找器，而不是调用静态对象

更新

---

瘦读取层指的是使用简化的读取模型而不是富域对象。它与DI无关，不管查询服务是如何构建的，也不管由谁构建的，重要的是不要在查询中涉及业务对象。

读/写分离与依赖项注入等编码技术完全无关。与以前的组合读/写模型相比，您的读模型的用途更少。你能考虑抛弃所有的服务器端代码，只使用数据库的本地REST API吗？您是否可以连接控制器以直接使用SQL查询数据库并以JSON的形式返回数据？您是否需要一个类似于存储库的通用模式来处理特定的读取请求？

是的，您对静态类的看法是正确的，我错了。我将编辑该问题以在控制器方法中实例化该类。我仍然担心的是，通过在我的读取模型中使用DI，我正在摆脱读取模型的瘦数据层概念。您的读取模型是DTO。您使用DI来保持事物的解耦，它与读取模型无关。瘦数据层是让查询服务直接使用简化模型，而不是丰富的复杂模型。不要想得太多，保留DI容器。我对保留读取层的理解是保持整个过程的精简，即从DB获取数据并在屏幕上显示。你是说我应该更狭隘地看待这一点，只专注于保持查询方面并精简DTO吗？即使DI仍然是一个很薄的层，你也可以使用DI来获取服务实例，而不是手动填充或填充依赖项，仅此而已。“精简”部分是关于不使用域对象进行查询，与如何实例化查询对象无关。实际上，有一个查询处理程序模式需要DI容器。如果您通过总结最后几条评论来添加到您的答案中，我将接受您的答案。出于未来读者的目的，我不希望官方答案仅仅是关于静态类的事情，因为我编辑了该部分。另外，您的评论更全面地回答了我的问题。但是，如果您想对您的

个人

应用一些交叉关注，该怎么办？当您将其应用于静态类时，这将很难做到（并且会有大量重复代码），而如果插入接口，您可以使用装饰器、代理、拦截器或工具箱中的任何模式来包装该实例。我的观点是，依赖项注入之类的事情会增加架构开销。因此，读写分离与编码技术有关，因为建议保持读模型的精简。