你能给我一个没有框架的依赖注入的例子吗?

时间:2014-12-13 03:53:45

标签: java spring dependency-injection inversion-of-control

我想减少两个组件之间的耦合,然后我想到了dependency injection,但很长一段时间,我只是使用Spring来实现它。但是现在,我正在开展一个不适合使用这个框架的项目(它太重了)。

那么你能举个例子来为我自己实施dependency injection吗?

2 个答案:

答案 0 :(得分:2)

Dependency Injection是一种在没有框架支持的情况下可以轻松使用的模式。有些人甚至更喜欢没有框架支持,但至少,框架是否真正有益取决于way you use such framework以及您正在构建/维护的应用程序的类型和大小。

依赖注入只是将依赖项从外部注入组件。最常见和建议的方法是通过构造函数注入。这意味着类应该将其所有依赖项指定为构造函数参数。

您应该始终将代码设计为好像根本没有DI框架;你的应用程序代码应该忘记这种框架的存在。这意味着您永远不应该使用特定于框架的属性来装饰您的代码。它们会污染您的代码并导致供应商锁定。如果您使用的DI库需要使用属性,请切换到其他库。

依赖注入的使用将在整个应用程序中“冒泡”。这意味着应用依赖项注入模式的类将把依赖项创建的责任移到调用堆栈上。这意味着该类的使用者现在负责创建其依赖项。但是,由于该消费者也应该应用依赖注入,这意味着它推动了再次创建依赖关系的责任。当所有类都应用依赖注入模式时,这意味着需要在应用程序的单个位置创建完整的对象图。这实际上是件好事。这个地方叫做composition root

同样,您不需要使用DI库(a.k.a. IoC容器),您的应用程序代码绝对不应该依赖它。您应该应用依赖注入模式(和SOLID原则)来使您的应用程序可维护。可以使用DI库来使您的组合物可维护,但只有在它使组合物根更易于维护时才能使用它。不使用DI库可以为您创建对象图提供完整的编译时支持。使用DI库会使您失去这种编译时支持,因此使用它的优点应该超过失去编译时支持的缺点。此外,您需要确保在应用程序启动期间或至少在测试套件中验证对象图的构建。如果您的DI容器难以实现,则切换库或手动构建对象图可能是更好的选择。

答案 1 :(得分:0)

你为什么要重新发明轮子? Java拥有出色的CDI框架。它轻巧易用。有关详细信息,请参阅http://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html