Question

我正在尝试为自己定义一些依赖注入指南。在为通过构造函数或setter注入注入的类定义依赖项时，应该是正确的粒度？该类可以是服务，存储库等。假设有一个存储库类，如下所示：

public class ProductRepository 
{
    //Option-A
    public ProductRepository(DataSource dataSource)
    {
    }

    //Option-B      
    public ProductRepository(SqlSession sqlSession)
    {
    }

    //Option-C
    public ProductRepository(SqlSessionTemplate sqlSessionTemplate)
    {
    }
}

上述类所需的最小依赖项是DataSource接口。存储库类在内部使用SqlSessionTemplate（SqlSession接口的实现）。如代码所示，构造函数有3种选择来进行构造函数注入。以下是我的理解：

选项-A（数据源依赖关系） 这是存储库类的最小依赖项。从消费者的角度来看，这个构造函数是正确的选择，但从单元测试的角度来看它并不合适，因为DataSource在存储库实现中由SqlSessionTemplate内部使用。

选项-B（SqlSession依赖关系） 从单元测试的角度来看，这是正确的选择，但不是从消费者的角度来看。此外，存储库实现与接口的特定实现紧密耦合，即SqlSessionTemplate。因此，如果使用者传递除SqlSessionTemplate之外的一些不同的SqlSession接口，它将无法工作。

选项-C（SqlSessionTemplate依赖关系） SqlSessionTemplate是一个实现而不是一个接口似乎不适合单元测试。此外，它对消费者不利，因为与DataSource相比，实例化SqlSessionTemplate更加复杂。因此丢弃此选项。

选项-A和选项-B似乎是可用的选择。但是，在消费者观点和单位测试观点之间存在权衡，反之亦然。

我是依赖注入的新手。我向DI专家寻求建议。什么是正确的解决方案（如果有的话）？在上述情况下你会怎么做？

感谢。

Answer 1

这是存储库类的最小依赖项。

我认为这是确定合适的耦合量的起点。您应该注射不超过或少于满足要求所需的注射量。

这是一个非常一般的指导方针，几乎相当于“它取决于”，但它是开始思考它的好方法。我不太了解DataSource，SqlSession或SqlSessionTemplate在上下文中的回答。

存储库类在内部使用SqlSessionTemplate （SqlSession接口的实现）

为什么存储库不能简单地将接口用作依赖？接口是否未涵盖实施的所有公共方法？如果没有，界面是否是一个有用的抽象？

我无法完全拼凑你想要做的事情以及依赖关系如何运作，但我最好的猜测是：

您需要通过构造函数注入SqlSession和DataSource，或
您需要通过Repository的构造函数注入SqlSession，并将DataSource注入SqlSessionTemplate的构造函数

Answer 2

您正在谈论对您的存储库进行单元测试，但这通常是无用的，因为存储库是您通往数据库的网关并且与它有很强的耦合。单元测试应该独立完成，但只能使用数据库测试存储库。因此：集成测试。

如果您能够从存储库中抽象出特定于数据库的逻辑（就像您正在做的那样），那么就没有什么可以进行测试了，因为存储库的职责是与数据库进行通信。如果还有很多东西需要测试，那么......在这种情况下，您的存储库类可能违反了Single Responsibility Principle，这使得您的存储库难以维护。

因此，您通常会使用数据库测试存储库本身，从测试角度来看，注入的内容并不重要，因为您必须以这样的方式构建存储库，使其能够连接到数据库无论如何。

在进行构造函数或setter注入时，依赖项的正确粒度是多少？

2 个答案: