0

据我了解，DI的实现基于

1.ISample接口

2.示例：ISampleInterface

3. ISampleInterface 与 Sample 的配置绑定。

4.和构造函数注入

ISampleInterface _sampleInterface;

Constructor(ISampleInterface sampleInterface)
{
  _sampleInterface = sampleInterface;
}

其余的事情由 DI 处理。

但如果在某些情况下，在具体的接口实现类中，可能需要“新建”初始化。那我该怎么办？

在Sample类中，

如果我需要申报

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

或在Sample类中。可能需要为接口方法实现编写下面的代码。

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 时手动创建对象是否正确？按照例子。或者他们有什么方法可以避免这种情况？

4

1 回答 1

0

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

依赖注入模式在这里为您提供了一种如何实现组件松散耦合的方法。它将创建此类组件的责任转交给 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

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

于 2013-01-29T22:16:25.923 回答