我们是否有效地使用IoC？

Question

所以我的公司使用Castle Windsor IoC容器,但感觉"关闭":

• 所有数据类型都在代码中注册,而不是在配置文件中注册.
• 所有数据类型都是硬编码的,以使用一个接口实现.事实上,对于几乎所有给定的接口,只有一个实现.
• 所有已注册的数据类型都具有默认构造函数,因此Windsor不会为任何已注册的类型实例化对象图.

设计系统的人坚持认为IoC容器使系统更好.我们有1200多个公共类,所以它是一个很大的系统,你期望找到像Windsor这样的框架.但我仍然持怀疑态度.

我的公司是否有效地使用IoC？使用Windsor的新对象比使用new关键字的新对象更有优势吗？

Answer 1

简短回答:不,贵公司没有有效使用DI.

稍微长一点的答案:主要问题是所有类都有默认的构造函数.在这种情况下,那么如何解决依赖关系呢？

你的构造函数都有像这样的硬编码依赖:

public Foo()
{
    IBar bar = new Bar();
}

在这种情况下,如果不重新编译该应用程序,则无法更改依赖关系.

更糟糕的是,他们可能会使用静态服务定位器反模式:

public Foo()
{
    IBar bar = Container.Resolve<IBar>();
}

DI容器应解析应用程序的组合根中的整个依赖关系图并完成.

通常,通过在代码中使用启发式方法来配置容器,最好使用Convention over Configuration.应该为少数情况保留XML配置,在这些情况下,您需要能够重新配置依赖关系而无需重新编译,这应该只是一个小子集.简而言之,我认为在代码中配置容器没有固有的问题.事实上,这是首选方法.

每个接口只有一个实现也不是问题.这是一个开始,如果应用程序真正松散耦合,它就是一个不断打开的机会之窗.迟早你很可能会引入替代实现,但如果接口已经到位并且整个代码库遵循Liskov替换原则,那么最好这样做.