对数据对象使用依赖注入？

我只是在学习有关依赖项注入的知识，并且陷入了困境。依赖注入建议通过构造函数发送依赖类，但是我想知道对于数据对象是否需要这样做。由于单元可测试性是DI的主要优点之一，因此仅存储数据而不对任何过程进行数据测试的数据对象都会使DI成为不必要的复杂性层，或者它甚至仍然有助于显示依赖性与数据对象？

Class DO{
    DO(){
        DataObject2List = new List<DO2>();
    }

    public string Field1;
    public string Field2;
    public List<DO2> DataObject2List;
}

Class DO2{
    public DateTime Date;
    public double Value;
}

我想建议您在这里使用一些术语的说明，特别是“依赖关系”和“依赖关系注入”。

依赖关系：

“依赖关系”通常是一个复杂的对象，它执行某些功能可能是另一个类所依赖的。一些经典的例子是记录器，数据库访问器或处理特定业务逻辑的某些组件。

甲数据仅像DTO或值对象对象通常不被称为“依赖”，因为它们不执行一些必要的功能。

一旦以这种方式看待它，示例中所做的工作（通过构造函数将对象与对象列表组成）完全不应被视为“依赖注入”。它只是设置一个属性。由您决定是通过构造函数还是以其他方式提供它，但是仅通过构造函数传递它并不会使其依赖注入。DOD02

依赖注入：

如果您的DO2类实际上提供了DO该类所需的一些其他功能，那么它确实是一个依赖项。在这种情况下，依赖类DO应当依赖于一个接口（例如ILogger或IDataAccessor），然后依赖于调用代码来提供该接口（换句话说，就是将其“注入”到DO实例中）。

以这种方式注入依赖关系会使DO对象更加灵活，因为每个不同的上下文都可以提供其自己的DO对象接口实现。（请考虑单元测试。）

我将尽我所能消除这个问题中的困惑。

首先，“数据对象”不是一个有意义的术语。如果此对象的唯一定义特征是它没有方法，那么它根本不应该存在。有用的无行为对象应至少属于以下子类别之一：

• 值对象或“记录”完全没有身份。假定环境支持，它们应该是具有引用时复制语义的值类型。由于这些是固定的结构，因此VO只能是原始类型或固定的原始序列。因此，VO不应具有任何依赖性或关联性；任何非默认构造函数都将仅出于初始化值的目的而存在，即因为无法将其表示为文字。

• 数据传输对象经常被错误地与值对象混淆。DTO 确实具有身份，或者至少可以。DTO的唯一目的是促进信息从一个域流向另一个域。他们从没有“依赖”。它们可能具有关联（即与数组或集合关联），但是大多数人更喜欢将它们弄平。基本上，它们类似于数据库查询输出中的行。它们是通常需要保留或序列化的临时对象，因此不能引用任何抽象类型，因为这会使它们不可用。

• 最后，数据访问对象为某种数据库提供了包装或外观。这些显然具有依赖性-它们取决于数据库连接和/或持久性组件。但是，它们的依赖关系几乎总是在外部进行管理，并且对调用方完全不可见。在Active Record模式中，框架是通过配置来管理所有内容的。在较旧的（按今天的标准古老）的DAO模型中，您只能通过容器构造这些模型。如果通过构造函数注入看到其中之一，我将非常非常担心。

您可能还考虑了一个实体对象或“业务对象”，在这种情况下，您确实想支持依赖项注入，但不以您的想法或出于您考虑的原因。这不是为了用户代码，而是为了实体管理器或ORM，后者将以静默方式注入一个代理服务器，该代理服务器会拦截该代理服务器以执行诸如查询理解或延迟加载之类的幻想。

在这些示例中，通常不提供注入的构造函数。相反，您只需要将属性设置为虚拟并使用抽象类型（例如IList<T>而不是List<T>）即可。其余的发生在幕后，没有人是明智的。

因此，总而言之，我不需要将可见的DI模式应用于“数据对象”，甚至可能是红色标记。但是在很大程度上，这是因为对象的存在本身就是一个危险信号，除非专门用于表示数据库中的数据。在几乎所有其他情况下，它都是代码气味，通常是Anemic域模型的开始，或者至少是Poltergeist的开始。

重申：

1. 不要创建“数据对象”。
2. 如果必须创建“数据对象”，请确保其具有明确定义的用途。该目的将告诉您DI是否合适。首先，对于不应该存在的对象做出有意义的设计决策是不可能的。

鳍。

在您的示例中，DO没有任何功能依赖性（基本上是因为它什么都不做）。它确实依赖于具体类型DO2，因此您可能希望引入一个抽象接口DO2，以便使用者可以实现自己的子类具体实现。

真的，您会在这里注入什么依赖性？

由于这是数据访问层中的数据对象，因此它应直接依赖于数据库服务。您可以为构造函数指定DatabaseService：

DataObject dataObject = new DataObject(new DatabaseService());
dataObject.Update();

但是，注入不一定必须在构造函数中。另外，您可以通过每个CRUD方法提供依赖关系。与以前的方法相比，我更喜欢这种方法，因为在您真正需要持久存储数据对象之前，您不需要知道它在哪里持久。

DataObject dataObject = new DataObject();
dataObject.Update(new DatabaseService());

你肯定不希望隐藏的建设走在CRUD方法！

public void Update()
{
    // DON'T DO THIS!
    using (DatabaseService dbService = new DatabaseService())
    {
        ...
    }
}

另一种选择是通过可重写的类方法构造DatabaseService。

public void Update()
{
    // GetDatabaseService() is protected virtual, so in unit testing
    // you can subclass the Data Object and return your own
    // MockDatabaseService.
    using (DatabaseService dbService = GetDatabaseService())
    {
        ...
    }
}

最后一种选择是使用单例样式的ServiceLocator。尽管我不喜欢这个选项，但是它可以进行单元测试。

public void Update()
{
    // The ServiceLocator would not be a real singleton. It would have a setter
    // property so that unit tests can swap it out with a mock implementation
    // for unit tests.
    using (DatabaseService dbService = ServiceLocator.GetDatabaseService())
    {
        ...
    }
}