c# - 我应该将存储库接口(interface)与域模型分离吗

Question

假设我有一些 DDD 服务需要一些 IEnumerable<Foo>执行一些计算。我想到了两种设计:

1. 使用 IFooRepository 抽象数据访问界面，比较典型

   public class FooService
   {
       private readonly IFooRepository _fooRepository;
   
       public FooService(IFooRepository fooRepository)
           => _fooRepository = fooRepository;
   
   
       public int Calculate()
       {
           var fooModels = _fooRepository.GetAll();
           return fooModels.Sum(f => f.Bar);
       }
   }
   

2. 不要依赖IFooRepository抽象和注入(inject) IEnumerable<Foo>直接

   public class FooService
   {
       private readonly IEnumerable<Foo> _foos;
   
       public FooService(IEnumerable<Foo> foos)
           => _foos = foos;
   
   
       public int Calculate()
           => _foos.Sum(f => f.Bar);
   }    
   

在我看来，第二种设计似乎更好，因为 FooService现在不关心数据来自哪里和Calculate成为纯域逻辑(忽略 IEnumerable 可能来自不纯来源的事实)。

使用第二种设计的另一个论据是当IFooRepository通过网络执行异步 IO，通常需要使用 async-await喜欢:

public class AsyncDbFooRepository : IFooRepository
{
    public async Task<IEnumerable<Foo>> GetAll()
    {
        // Asynchronously fetch results from database
    }
}

但是因为你需要async all the way down , FooService现在被迫将其签名更改为 async Task<int> Calculate() .这似乎违反了 dependency inversion principle .

但是，第二种设计也存在问题。首先，您必须依赖 DI 容器(此处以 Simple Injector 为例)或组合根来解析数据访问代码，例如:

public class CompositionRoot
{
    public void ComposeDependencies()
    {
        container.Register<IFooRepository, AsyncDbFooRepository>(Lifestyle.Scoped);

        // Not sure if the syntax is right, but it demonstrates the concept
        container.Register<FooService>(async () => new FooService(await GetFoos(container)));
    }

    private async Task<IEnumerable<Foo>> GetFoos(Container container)
    {
        var fooRepository = container.GetInstance<IFooRepository>();
        return await fooRepository.GetAll();
    }
}

同样在我的特定场景中，AsyncDbFooRepository需要某种运行时参数来构造，这意味着您需要一个 abstract factory build AsyncDbFooRepository .

有了抽象工厂，现在我要管理AsyncDbFooRepository下所有依赖的生命周期(AsyncDbFooRepository 下的对象图并不简单)。我有一种预感，如果我选择第二种设计，我会错误地使用 DI。

---

总而言之，我的问题是:

1. 我在第二个设计中是否错误地使用了 DI？
2. 如何为我的第二个设计令人满意地组合我的依赖项？

Answer 1

async/await 的一个方面是它根据定义 需要像您正确声明的那样“一直向下”应用。但是，您不能阻止使用 Task<T>注入(inject) IEnumerable<T> 时，正如您在第二个选项中所建议的那样。您将必须注入(inject) Task<IEnumerable<T>>到构造函数中以确保异步检索数据。注入(inject) IEnumerable<T> 时这意味着您的线程在枚举集合时被阻塞 - 或者 - 在对象图构造期间必须加载所有数据。

然而，由于我解释的原因 here，在对象图构造期间加载数据是有问题的.除此之外，由于我们在这里处理数据集合，这意味着必须在每次请求时从数据库中获取所有数据，即使可能不需要甚至使用所有数据。这可能会导致相当大的性能损失。

Am I using DI incorrectly in my second design?

这很难说。一个IEnumerable<T>是一个流，所以你可以认为它是一个工厂，这意味着注入(inject)一个 IEnumerable<T>不需要在对象构造期间加载运行时数据。只要满足该条件，就会注入(inject) IEnumerable<T>可能没问题，但仍然无法使系统异步。

然而，当注入(inject) IEnumerable<T>你可能最终会产生歧义，因为可能不太清楚注入(inject) IEnumerable<T> 意味着什么。 .该集合是否是延迟评估的流？是否包含T的所有元素.是T运行时数据还是服务？

为防止这种混淆，将此运行时信息的加载移到抽象后面通常是最好的做法。为了让您的生活更轻松，您也可以使存储库抽象成为通用的:

public interface IRepository<T> where T : Entity
{
    Task<IEnumerable<T>> GetAll();
}

这允许您拥有一个通用实现并为系统中的所有实体进行一次注册。

How can I compose my dependencies satisfactorily for my second design?

你不能。为此，您的 DI 容器必须能够异步解析对象图。例如，它需要以下 API:

Task<T> GetInstanceAsync<T>()

但是 Simple Injection 没有这样的 API，任何其他现有的 DI 容器也没有，这是有充分理由的。原因是对象构造必须是 simple ，快速和reliable并且在对象图构造期间执行 I/O 时会丢失它。

因此，不仅您的第二种设计不可取，而且在对象构造期间加载数据时，也不可能在不破坏系统的异步性并导致线程在使用 DI 容器时阻塞的情况下这样做。