Question

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)
   {

    }

}

在存储库中保存数据时，我想从Reference数据存储库中获取数据以设置一些属性。

问题是一个存储库应该知道其他存储库吗？我正在使用依赖注入来设置引用数据存储库，我应该在存储库中设置存储库吗？

Answer 1

你可以，DI只是说一个对象依赖于另一个，但不负责实例化依赖。

但是我会将read repo注入write repo。读写就是这样。获取对象并保存对象。实际上还有责任改变对象。这将发生在另一个组件中。像控制器动作或服务门面。

Answer 2

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

存储库模式就是将数据访问层与业务层分离，并通过耦合不同的存储库，让您的业务逻辑滑入数据层，这与使用此设计模式的初始目的相悖。

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

Answer 3

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

不应该混淆不同的逻辑，每个存储库都封装一个。

但是如果你需要这样的东西，你可以写一个RepositoryManager类，它处理不同存储库之间的纠缠。

Answer 4

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

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

请在此处查看DomainRepository如何同时具有读写功能。作为一个原则，如果它用于不同的目的，我不会重新考虑另一个存储库。

如果让某些方法重复，那么我将其设为内部和静态，传递所需的所有参数，但我不会注入另一个回购。可能在95％的情况下，如果每个存储库都有明确的责任并且只提供一个上下文，则不需要这样做。

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

存储库模式混乱

4 个答案: