我一直在阅读有关Spring的内容,虽然它声称是一种不那么复杂的EJB替代品,但我很难绕过它。实现依赖注入比采用Spring方法更简单吗?
答案 0 :(得分:9)
为什么不在没有框架的情况下这样做呢?
询问你的类依赖什么,然后通过(比如说)构造函数注入这些对象。
一些提示:
e.g。只需创建一个带有构造函数的类:
public TradeSaver(final ITradeValidator validator, final ITradeDatabase db);
(其中两个参数都是接口),然后您可以注入TradeSaver
依赖的核心组件(验证和数据库保存),并可选择为测试,不同部署等提供不同的实现。
答案 1 :(得分:3)
Google Guice是一个极简主义的DI框架。
答案 2 :(得分:2)
尚未提及的另一个选项是 Yan 。我过去曾经使用它,它非常轻巧,极简。这是一个关于它做什么(以及如何)的单页介绍的链接:
答案 3 :(得分:2)
就DI和IoC而言,它可能不会比picocontainer更小。
我更喜欢Tapestry,但Google Guice非常相似并且被广泛采用,所以这可能是更好的选择,因为它更容易找到教程等。
答案 4 :(得分:2)
我强烈建议您尝试使用Spring。它在初始阶段比Guice复杂一点,但是,其他API和包含实用程序(LDAPTemplate,JDBCTemplate,HibernateTemplate,Validators等)的包装器非常值得入场。
答案 5 :(得分:1)
从本质上讲,依赖注入只是构建代码以实现组件可重用性的一种方式。它不需要使用容器。它只是意味着您将组件的“新”运算符的任何使用移动到应用程序的开头。例如,您的应用程序入口点可能如下所示:
IZooDataRepository repository = new SqlZooDataRepository(somehost, someparam);
IMonkeyManager monkeyManager = new MonkeyManager(repository);
IZebraManager zebraManager = new ZebraManager(repository);
ZooProgram program = new ZooProgram(monkeyManager, zebraManager);
program.run();
这个阶段被称为“对象图构造”。您可以将只知道其协作者的对象连接到这些接口的特定实现的接口。
如果您在实践中有数百个课程,这种启动布线可能会变得非常漫长和复杂。这就是DI容器被发明的原因:它们以某种方式替换了对象图构造代码,例如:像这样:
Container container = new Container(someconfigurationparameters);
ZooProgram program = (ZooProgram) container.Create(ZooProgram.class);
program.run();
容器生成的对象图的配置通常通过XML文件,类上的属性或使用代码定义的绑定来完成。
答案 6 :(得分:1)
PicoContainer是开始使用DI的最简单方法:
假设我们
public class A implements IA {
public A(IB dependency){
...
}
}
public class B implements IB {
}
然后
pico = new DefaultPicoContainer();
pico.addComponent(A.class);
pico.addComponent(B.class);
IA a = pico.getComponent(IA.class); // a is an instance of A with an instance of B passed to the constructor
答案 7 :(得分:0)
我强烈建议您研究JSR-330实现,因为这些应该是未来的标准。在JEE6中有一个,但对你来说可能有点矫枉过正。我相信 Caucho CanDI也可以独立运行。
答案 8 :(得分:-3)