1.3.3 企业级应用中的依赖注入

作者: [美]Craig Walls Ryan Breidenbach著/毕庆红/王军等译 出处:人民邮电出版社 　2008-07-25 13:33　   砖    好    评论  条 　进入论坛

阅读提示：《Spring in Action（第二版）中文版》第1章开始Spring之旅,这一章主要讲述的是Spring核心模块、解耦应用对象和使用AOP管理交叉问题，本小节为大家介绍企业级应用中的依赖注入。

1.3.3  企业级应用中的依赖注入

假设你被要求写一个在线购物应用。该应用需要一个订单服务组件来处理所有与订单相关的函数。图1.5演示了一个Web层Checkout组件（可能是一个WebWork动作或一个Tapestry页面）可以访问订单服务的几种方法。

图1.5  传统的服务查询方法会导致付帐 对象和订单对象之间的紧耦合

Checkout组件（也许是WebWork动作或Tapestry页面）会访问订单服务。一个简单的方法是在需要的时候直接实例化订单服务。除了直接耦合Web层到指定服务类之外，这个方法还会导致创建不经济的OrderServiceImpl类。

如果订单服务通过2.x EJB来实现，可以通过JNDI来检索主接口来访问该服务，然后它被用来访问EJB服务接口的实现。此时，Web层不再耦合到特定接口，但是它耦合到JNDI和EJB 2.x编程模型。

作为EJB 3 bean，可以从JNDI直接查找订单服务（不需要通过主接口）。而且，这不会有任何到特定实现类的耦合，但是它对JNDI有一个依赖。

使用或不使用EJB，都可以选择隐藏服务寻址之后的查找细节。这会解决与其他方法的耦合关系，但是现在Web层仍然会耦合到服务定位器。
所有这些方法的关键问题是Web层组件也包含在其依赖组件中，它知道有关订单服务内容及其实现方法的更多细节。

图1.6  通过将OrderService注入到Checkout组件中， 那么实现服务的地方就可以检索到Checkout

知道太多依赖对象的内容会导致紧密耦合代码，知道越少耦合就越松散。参看图1.6，该图显示了Checkout组件如何给予了一个OrderService，而不是主动请求。

现在，让我们看看如果使用DI来如何实现这种方案：

没有查找代码！到OrderService（它是一个接口）的引用将通过setOrderService()方法来给定。Web组件并不知道OrderSerive来自何处。它可以由Spring注入或者可以通过显示调用setOrderService()来手动注入。它也不知道OrderService是如何实现的——它仅知道通过OrderService接口来访问。使用DI，可以释放应用对象获取其依赖对象的负担，从而可以集中除了自己的任务，相关依赖对象在需要的时候才使用。

依赖注入是一种松散耦合代码，这样可以尽可能是的应用对象之间保持疏远的关系。但是，我们只是简单介绍了Spring容器和DI。在第2章和第3章中，我们将就介绍在Spring容器中配置对象的多个方法。

依赖注入只是Spring提供的一种技术，它支持松散耦合。面向切面编程技术提供了另外一种解耦合的功能，它将应用功能（例如安全和事务）和对象分开。让我们快速地看一下Spring对AOP的支持。

回书目   上一节   下一节