Design patterns 存储库模式混乱

在存储库中保存数据时，我希望从参考数据存储库中获取数据以设置一些属性

问题是一个存储库是否应该知道另一个存储库？

---

我正在使用依赖项注入来设置参考数据存储库，我应该在存储库中设置存储库吗？

可以，DI只是声明一个对象依赖于另一个对象，但不负责实例化依赖项

---

但是，我会将读repo注入写repo。读和写就是这样。获取对象并保存该对象。仍然有责任实际更改对象。这将发生在另一个组件中。就像控制器操作或服务外观。

我认为存储库不应该相互了解。此附加行为属于您的服务或业务层

存储库模式是将数据访问层与业务层分离，通过耦合不同的存储库，您可以让业务逻辑滑入数据层，这与使用此设计模式的最初目的背道而驰

---

顺便说一句，将改变数据的方法与读取数据的方法分开是一种很好的做法。

所描述的存储库模式是关于逻辑和数据的封装 如何将检索数据并将其映射到实体模型的逻辑与 作用于模型的业务逻辑

不需要混淆不同的逻辑，每个存储库封装一个逻辑

但是如果你需要类似的东西，你可以编写一个RepositoryManager类，

---

它处理不同存储库之间的纠缠。

我为特定上下文保留单独的存储库。虽然查询存储库只是读取，但它通常为UI服务。写存储库也有一些读取，但也有为域服务的读取

public class CarRepository:IC
{ 
    public IRD ReferenceDataRepositry{get;set;}
    public string SaveCar(Car car)
    {
        //get data from reference data repository
    }
}

public class ReferenceDataRepository:IRD
{
   public string Get(string id)
   {

    }

}

在这里可以看到DomainRepository如何同时具有读取和写入功能。原则上，如果另一个存储库有不同的用途，我不会重用它

事件，如果某个方法将是重复的，那么我将其设置为内部和静态，传递它所需的所有参数，但我不会再注入另一个repo。在95%的情况下，如果每个存储库都有明确的职责并且只服务于一个上下文，则可能不需要这样做

这也意味着不要使用通用存储库。根据层/上下文需要设计每个repo，不要落入“我应该尽可能多地重复使用”的陷阱。在这种情况下，重用是好的，但很棘手

public interface DomainRepository
{
 Entity Get(int id);
 bool VerifySomeAspect();
 Save(Entity data);
}