序依赖注入技术(dependencyinjection)被世人所认知和

序依赖注入技术(dependencyinjection)被世人所认知和

ID:35128650

大小:94.50 KB

页数:20页

时间:2019-03-19

序依赖注入技术(dependencyinjection)被世人所认知和_第1页
序依赖注入技术(dependencyinjection)被世人所认知和_第2页
序依赖注入技术(dependencyinjection)被世人所认知和_第3页
序依赖注入技术(dependencyinjection)被世人所认知和_第4页
序依赖注入技术(dependencyinjection)被世人所认知和_第5页
资源描述:

《序依赖注入技术(dependencyinjection)被世人所认知和》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、序:依赖注入技术(DependencyInjection)被世人所认知和使用有一段时间了。近来,越来越多的人开始使用它的原理来设计、开发、和单元测试Java程序。一些很优秀很有意思的开源框架也由此开发出来,比如SpringFramework和GoogleGuice等等。译者翻译的这篇近两年前的文章,对于人们了解和学习DependencyInjection的基本原理应该是有裨益的。就DependencyInjection目前在业界的直译(依赖注入)而言,译者认为不明了。所以以下就还一直使用英文。另请注意,这项技术并不是将依赖性进行注入,而是一些功能和资源的注入,请读者不要望文生义

2、。原文:范畴这篇文章从较高的层次来一览DependencyInjection(DI)技术。它的目的是在如何使用几种DI容器的背景下,把DI技术概念性地介绍给初学者。是DI还是IOC(反向控制)?当前的许多资料通常将DI和IOC混为一谈。就我个人而言,DI应该是一个更具体的名字。我能想像在许多情况下使用IOC的时候,不见得最后的模式就是以解决依赖性为重心(比如从一个控制台应用程序到一个窗口事件循环)。但是,如果你更习惯IOC,你基本上可以将以下文章里的DI换成IOC来读。IOC有多种类别,像一类,二类,三类。这些类别间的不同不在本文的讨论范围之内。另请注意我在本文里大量使用了服务

3、端(Service)词。请不要将它混淆为以服务为导向的框架(SOA)。我这里的意思只是用用户端来代表用户端组件,服务端来代表服务端组件。DI的简要介绍简要介绍情境一假设你在一个将出差当成家常便饭的公司工作。通常来说,你乘飞机来旅行。每次你赶飞机时,总是要安排taxi。你认识航空公司订票的人员,出租车公司安排taxi送你到机场的人员。你知道他们的电话,你知道通常订票的谈话内容。你的典型的旅行步骤如:·决定目的地,和希望到达时间;·给航空公司打电话,将必要的旅行信息传达出去,用以订票·给出租公司打电话,要求taxi从你住地送你到机场去赶某一具体航班(出租公司可能需要联络航空公司来得

4、到航班的起飞时间表,机场信息,并计算从你住地至机场的的具体时间,及相应的到达你住地的时间)·获取机票,赶上taxi,开始出差之旅如果现在你的公司突然更换原先订票的经纪以及相应的交流手段,你可能被迫进入重新熟悉的境地:·新的经纪公司,他们的交流方式(比如说,如果新的经纪通过互联网来做生意,而不是原来的电话)·用以成交的典型的谈话方式的次序(是数据,而不再是声音)不仅仅是你,很可能你的许多同事也要对此变化进行适应。适应的过程往往要花上可观的时间。情境二现在让我们来假设整个程序有一点点不同。你们公司有一个行政部门。当你需要出差旅行的时候,行政部门的互动电话系统会给你打电话(事实上是将

5、你和订票经纪公司挂起钩来)。在电话上,你只需回答特定的一套问题,来讲出你的目的地和需要的到达时间。机票订票系统是专为你们设计的,出租公司将计划好taxi的时间,同时,机票也会给你送上门来。如果现在订票的经纪更换了的话,行政部门会知会这个变更,也许他们会相应调整订票经纪的工作流程。互动的电话系统可以重新程序化,以便于和经纪在互联网上沟通。但是,你和你的同事们不需要有任何的重新适应过程。你仍旧只需照先前的程序走就行了(所有的调整都由行政部门去做了)依赖注入(DependencyInjection)在上述两个情境中,你是客户,你依赖于经纪提供的服务。但是,情境二有些不同:·你不需要知

6、道订票经纪人和电话-必要的话,公司行政部门会打电话给你·你不需要知道行政部门和订票经纪的交流程序和方式,虽然你知道如何与行政部门一个特定的交流方式·你不需要作出任何调整,即使当给你提供服务的经纪有变更的时候这就是现实生活中的依赖性注入(DI)。这种方式看上去省不了你什么,但是当你把它应用到一个大公司里去时,他的节省是很可观的。在软件领域里的DI软件的组件(用户端)通常是一整套相互作用的组件中的一部分,这一整套组件又会依赖于一些其他的组件(服务端)来完成它们的预定目标。在许多情况下,它们需要知道和哪些组件打交道,在哪里可以找到那些组件,以及如何和那些组件交流。如果获取到这些组件(

7、服务端)的方式改变时,这些变化可能迫使大量用户端的组件作出调整。有鉴于此,把代码结构化的一个方法是,将找到和实例化服务端组件的逻辑嵌入到用户端的组件里。另一个方法是将客户端对服务端的依赖性声明,让一些‘外在’的代码来承担找到和实例化服务端组件的任务,并提供相关的服务端的引用(reference)给客户端。后一种方式里,当寻找外在依赖性的方式变更时,客户端的代码通常不需要调整。这种实施的方法被认为是DI,前面提到过的那些’外在‘的代码可能是自己亲自写的,也可能是按一些现成的DI框架来实施的。那

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。