我们是否有效使用IoC？ [英] Are we using IoC effectively?

问题描述

因此，我的公司使用城堡温莎IoC容器，但以某种方式感觉关闭：

• 所有数据类型都以代码注册，而不是配置文件。


• 所有数据类型都是硬编码的，以使用一个接口实现。实际上，对于几乎所有给定的接口，只有一个实现才会有。


• 所有注册的数据类型都有一个默认构造函数，所以Windsor不会实例化任何对象图注册类型。

设计系统的人坚持使IoC容器使系统更好。我们有1200多个公共课程，所以它是一个大型系统，您希望希望找到像Windsor这样的框架。但我仍然怀疑。

我的公司是否有效使用IoC？使用Windsor新对象的优点是使用新关键字的新对象？

解决方案

简短的答案：否，您的公司没有有效地使用DI。

稍长一点的答案：主要的问题是所有类都有默认构造函数。在这种情况下，您如何解决依赖关系？

您的构造函数具有如下硬编码依赖关系：

  public Foo（）
 {
 IBar bar = new Bar（）; 
} 
  

在这种情况下，无需重新编译该应用程序就不能更改依赖项。 / p>

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

  public Foo（）
 {
 IBar bar = Container.Resolve< IBar>（）; 
} 
  

一个DI容器应该解析应用程序的组合根，并摆脱困境。 / p>

一般来说，使用代码中的启发式方法配置容器最好使用约定配置。应该为几个需要重新配置依赖关系而不重新编译的情况保留XML配置，这只应该是一个小的子集。简而言之，我没有看到在代码中配置容器的固有问题。实际上，这是首选方法。

每个接口只有一个实现也不是问题。这是一个开始，如果应用程序真正松散耦合，这是一个不断开放的机会之窗。迟早你很有可能会介绍其他的实现方法，但是如果接口已经到位，并且整个代码基础遵循 Liskov替换原则。

So my company uses Castle Windsor IoC container, but in a way that feels "off":

• All the data types are registered in code, not the config file.
• All data types are hard-coded to use one interface implementation. In fact, for nearly all given interfaces, there is and will only ever be one implementation.
• All registered data types have a default constructor, so Windsor doesn't instantiate an object graph for any registered types.

The people who designed the system insist the IoC container makes the system better. We have 1200+ public classes, so its a big system, the kind where you'd expect to find a framework like Windsor. But I'm still skeptical.

Is my company using IoC effectively? Is there an advantage to new'ing objects with Windsor than new'ing objects with the new keyword?

解决方案

The short answer: No, your company isn't using DI effectively.

The slightly longer answer: The main problem is that all classes have default constructors. When that's the case, then how do you resolve dependencies?

Either your constructors have hard-coded dependencies like this:

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

In which case you can't vary the dependencies without recompiling that application.

Even worse, they may use the Static Service Locator anti-pattern:

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

A DI Container should resolve the entire dependency graph in the application's Composition Root and get out of the way.

In general it's better to use Convention over Configuration by using a heuristic approach in code to configure the container. XML configuration should be reserved for those few cases where you need to be able to reconfigure dependencies without recompiling, which should only be a small subset. In short, I see no inherent problem with configuring the container in code. In fact, it's the preferred approach.

Having only one implementation per interface is not a problem either. It's a start, and if the application is truly loosely coupled, it's a constantly open window of opportunity. Sooner or later you will be very likely to introduce alternative implementations, but you can best do this if the interfaces are already in place and the entire code base adhere to the Liskov Substitution Principle.

这篇关于我们是否有效使用IoC？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！