Question

根据我的理解，DI的实施基于

1。 ISampleInterface

2。示例：ISampleInterface

3。配置与样本绑定ISampleInterface。

4. 和构造函数注入

ISampleInterface _sampleInterface;

Constructor(ISampleInterface sampleInterface)
{
  _sampleInterface = sampleInterface;
}

剩下的东西由DI处理。

但是如果有一些情况，在具体的Interface实现类中，可能需要“New”初始化。那我该怎么办？

在示例类中，

如果我需要申报

private const int _limitSize = 70;
limits = new int[_limitSize];

或示例类内。可能需要波纹管代码来编写接口方法实现。

Dictionary<string, object[]> arr = new Dictionary<string, object[]>()
{       
    {"name", new string[1]{listName}},          
};

实际实施

public string ContactListsAdd(string listName)
{
    Dictionary<string, object[]> arr = new Dictionary<string, object[]>()
    {       
        {"name", new string[1]{listName}},          
    };

    return callSomePrivateMethod("contact-lists.add", arr);         
}

所以我的问题是，当我们使用DI时，它是否是手动创建对象的正确方法。按照例子。或者他们有什么方法可以避免这种情况？

Answer 1

手动创建对象（如数据结构或通用对象）并不需要实现业务逻辑。但是，它们应该封装在您的bussines逻辑实现中。您不应手动创建的是业务组件（如存储库，服务等）

依赖注入模式在这里为您提供了一种如何实现组件的松散耦合的方法。它将创建这样的组件的责任转变为DI容器，因此您不需要在商务逻辑中创建这样的组件（即使您不倾向于使用松散耦合，在创建此类组件时也可能非常有用）组件变得复杂）。但是，我不建议将创建所有对象的责任移向DI容器。最后，组件的注册（绑定）可能变为：

Bind<IList<string>>().To<List<string>>();
Bind<IList<int>>().To<List<int>>();
Bind<IList<MyObject>>.To<MyObject>(); // what about constructor arguments ???
... and other mess of bindings

维持此类绑定将非常困难。如果您需要使用不同大小或不同的列表实现，该怎么办？你会在哪里获得一些内部类对象的构造函数参数？当然，你可以使用条件绑定，但它会成为一个大的条件绑定混乱。

DI可以避免手动创建对象吗？

1 个答案: