service - 依赖注入(inject)的最佳实践

Question

这是一个关于如何最好地进行 DI 的问题，因此它与任何特定的 DI/IoC 框架无关，因为应该根据模式和实践来选择框架，而不是相反，不是吗？

我正在做一个必须将存储库注入(inject)服务的项目，一个服务可能需要多个存储库，我很好奇以下方法之间的优缺点:

在服务构造函数中注入(inject)存储库

public class SomeService : ISomeService
{
    private IRepository1 repository1;
    private IRepository2 repository2;

    public SomeService(IRepository1 repository1, IRepository2 repository2)
    {
          this.repository1 = repository1;
          this.repository2 = repository2;
    }

    public void DoThis()
    {
          //Do something with repository1
    }
    public void DoThat()
    {
          //Do something with both repository1 and repository2
    }
}

注入(inject)一个自定义上下文类，其中包括任何服务可能需要但延迟实例化的所有内容(IServiceContext 将是 BaseService 中的 protected 字段)

public class SomeService : BaseService, ISomeService
{
    public SomeService(IServiceContext serviceContext)
    {
          this.serviceContext= serviceContext;
    }

    public void DoThis()
    {
          //Do something with serviceContext.repository1
    }
    public void DoThat()
    {
          //Do something with both serviceContext.repository1 and serviceContext.repository2
    }
}

注入(inject)只需要它们的方法

public class SomeService : ISomeService
{
    public void DoThis(IRepository1 repository1)
    {
          //Do something with repository1
    }
    public void DoThat(IRepository1 repository1, IRepository2 repository2)
    {
          //Do something with both repository1 and repository2
    }
}

一些指针将不胜感激，此外，在评估此类替代方案时我应该考虑哪些方面？

Answer 1

注入(inject)依赖项的首选方式是构造函数注入(inject)。

方法注入(inject)不太理想，因为这将很快导致必须在服务之间传递许多依赖项，并且会导致实现细节(依赖项)通过 API(您的方法)泄漏。

选项 1 和 2 都进行构造函数注入(inject)，这很好。如果您发现自己不得不在构造函数中注入(inject)太多依赖项，那就有问题了。要么你违反了Single Responsibility Principle ，或者您缺少某种 aggregate service ，这就是您在选项 2 中所做的。

但是，在您的情况下，您的 IServiceContext聚合服务将多个存储库组合在一起。一个类后面的许多存储库闻起来像 unit of work对我来说。只需添加 Commit IServiceContext 的方法你肯定会有一个工作单元。想一想:你不想注入(inject)一个IUnitOfWork吗？为您服务？