Question

我正在实现一种使用单个数据存储但使用单独的Query和Command模型的CQRS形式。对于我正在实现DDD的命令方面，包括存储库，IoC和依赖注入。对于Query端，我使用了here所述的Finder模式。基本上，finder类似于Repository，但只使用Find方法。

所以在我的应用程序中，在我的DAL中，我使用ADO.net和原始SQL来进行查询。 ADO.Net的东西都被抽象成一个很好的帮助器类，这样我的Finder类就可以简单地将查询传递给ADO帮助器，它返回查询器/映射器类变成读模型的通用数据对象。

目前Finder方法，比如我的命令存储库，是通过注入我的控制器的接口访问的，但是我想知道接口，DI和IoC是否对于查询端来说是过度的，因为我读过有关读取的内容CQRS建议使用＆＃34;瘦数据层＆＃34;。

为什么不直接访问我的Finders？我理解接口和DI的参数。即分离关注和可测试性。在SOC的情况下，我的DAL已经通过使用mapper类并将ADO.net内容放在辅助类中来分离出数据库特定的逻辑。就测试而言，根据this question单元测试，读取模型不是必需的。

总而言之，对于阅读模型，我可以这样做：

 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);
    }

 }

Answer 1

您是否正在使用 IoC和DI？那是坏事！无论如何，第二个版本更好，因为它不依赖于静态类。使用静态将打开潘多拉的盒子，不要这样做，因为使用静态的所有原因都是坏的。

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

<强>更新

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

Answer 2

读/写分离与依赖注入等编码技术完全无关。您阅读的模型所用的目的比以前的组合读/写模型少。您是否可以考虑放弃所有服务器端代码并仅使用数据库的本机REST API？你可以连接控制器直接用SQL查询数据库并将数据作为JSON返回吗？您是否需要类似通用存储库的模式来处理特定的读取请求？

CQRS - 是接口和;读取模型需要依赖注入？

2 个答案: