j2ee项目实训spring框架技术——第1章应用层spring框架技术及系统架构第1部分

j2ee项目实训spring框架技术——第1章应用层spring框架技术及系统架构第1部分内容摘要：

容器”。 为什么要进行如此的改变 ?有什么意义吗 ?  为什么不应该直接依赖 应用系统中的 “目标组件”。 依赖 在应用系统中 是客观存在的， 如果应用系统中不存在 依赖 关系，那意味着应用系统是由各个相互孤立的模块或者组件所构成，这样是无法构成一个相互协作和互相配合的有机的整体 ! 问题是应该依赖谁 ? 根据 Spring 框架中的 IoC 的设计原理，应用系统中的某个组件类应该依赖所在的上层容器而不要直接依赖目标组件类。 主要是由于目标组件 类有可能会 随着 应用系统的 需求的变化而经常 会发生 改变 和调整 ， 开发者当然也不 希望在应用系统中由于某个“方面”发生改变而相关联的 各个 组件 类 也必须跟着改变。 J2EE 平台中倡导多层架构中 分层的目的也就是 希望 能够达到良好的隔离。  哪又为什么可以依赖于“ IoC 容器（ Spring 框架）”。 由于容器相对于应用系统 本身 而言应该是相对的稳定的，不会频繁地发生改变 （当然，Spring 框架本身也会发生升级改变）。 如此，也就达到 将 应用系统中的 “可变”和“不变”部分相互 分离。 在 Spring 框架中为什么要提出“依赖注入”的设计理念 （ 1）主要的目的 软件系统开发中的各种理论、思想包括软件工程等都一直在提倡“软件重用”，但问题是又如何能够达到。 以及采用什么样的具体实现方法 ? Spring 框架中所提出的“依赖注入”的设计理念为“软件重用”的真正实现带来了可操作性的实现方法。 依赖注入的目标并非为软件系统带来更多的功能，应用它的目的是为了提升“组件重用”的概率，同时也为应用系统搭建出一个更加灵活、可扩展的平台。 因为，现在的企业级的应用系统的开发更加注重系统的安全性、稳定性、可扩展性和可移植性等目标。 （ 2） 应用 依赖注入 的 设计理念在系统架构 设计 方面所产生的效果 提高了组件的可移植性和可重用度，依赖注入 的 机制减轻了组件之间的依赖关系，因为 目标对象的创建并不是在源组件类中直接以编码方式产生的， 这也是 遵守 J2EE 平台倡导的 “松藕合”的系统开发要求 的。 （ 3） 应用 依赖注入 的 设计理念在系统 开发 实现方面所产生的效果 能够更简洁地编程应用 J2EE 平台中的 各种 复杂的技术实现 ，并使应用系统具有良好的杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权所有，盗版必究 ， 10/22 页 可扩展性和灵活性。 为了能够让读者对此有所体验， 下面通过一个在应用系统的 持久层开发实现中 DAO 组件中应用 DataSource 实现数据库连接的示例，来说明 Spring 框架 中的依赖注入是如何简化 系统 开 发实现。 【例 13】 某个 DAO 组件获得 DataSource 对象从而获得数据库连接对象的 示例 ?xml version= encoding=UTF8? !DOCTYPE beans PUBLIC //SPRING//DTD BEAN beans bean id=dataSource class= destroymethod=close property name=driverClassName value/value /property property name=url value jdbc:microsoft: /value /property property name=username valuesa/value /property property name=password value1234/value /property /bean bean id=userInfoDAOBean class= property name=dataSource ref bean=dataSource/ 杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权所有，盗版必究 ， 11/22 页 /property /bean /beans 上面的示例是将 Apache的 DBCP的数据库连接池的实现类 BasicDataSource的 对象实例注入到应用系统的 DAO组件中，从而可以避免由应用系统的开发者自己编程实现基于 JDBC 的 DataSource 接口的实现。 读者应该知道，对于数据库连接池的具体编程实现也不是所有的开发者都有能力能够编程实现的，因为它要考虑许多并发和线程等同步方面的技术，应该是有一定的技术的复杂性和难度的。 （ 4）在系统 的可维护性 方面所产生的效果 提高了应用系统的可移植性和可维护性，当应用系统中的某一环境参数发生变化，并不需要大量地修改程序中的代码，而只需要调整一下配置文件及配置文件中的参数。 比如对于 【例 13】 中的示例， 如果应用系统的数据库连接池的实现在应用系统的部署环境中，最终实际是 采用 应用 服务器 容器的 JNDI 形式的 数据库连接池的实现 方案 ，此时只需要更新DataSource 对象的 实例的 定义，而不需要修改应用系统中的 DAO 组件 中有关 的代码。 请见下面的 【例 14】 中所示的最后修改的结果。 【例 14】 应用容器的 JNDI 数据库连接池的实现 的示例，并请注意其中的黑体部分的内容。 ?xml version= encoding=UTF8? !DOCTYPE beans PUBLIC //SPRING//DTD BEAN beans bean id=dataSource class= property name=jndiName valuejava:/p/env/jdbc/dataSource/value /property /bean bean id=userInfoDAOBean class= property name=dataSource ref bean=dataSource/ 杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权所有，盗版必究 ， 12/22 页 /property /bean /beans 其中 UserInfoDAOBean 组件 假设 是一个运行在 J2EE 应用服务器容器如 Weblogic 或者Tomcat 等中的组件，而 DataSource 是 由 J2EE 应用服务器 容器 所创建的。 当系统中的 DAO组件在运行过程中将由 Spring IoC 容器动态注入，而 DataSource 的具体配置和初始化工作也将由 IoC 容器在运行期完成。 因此，从上面的两个示例的最终的实现，对比传统的如通过编码初始化 DataSource 对象实例的实现方式，基于依赖注入的系统实现是相当灵活和简洁的。 从上面的示例所反映出的编程实现的效 果 通过依赖注入的机制，开发者只需要通过简单地配置，而无需任何编程实现代码就可在应用系统的 UserInfoDAOBean 组件 中获得所需要的 DataSource 对象实例。 也就是UserInfoDAOBean 组件的开发者 只需利用容器注入的 DataSource 对象实例，完成自身的数据访问的各种 CRUD 的 访问 逻辑，而不用关心应用系统中后台具体的数据源来自何处、采用什么形式的具体 技术 实现等方面的问题。 （ 1） 提高了组件的可移植性和可重用度 假设应用系统的部署环境发生了变化，应用系统中的持久层中的各种形式的 DAO 组件需要脱离应用服务器容器而在容器之外独立运行。 由于失去了容器的支持，原本通过 JNDI获取 DataSource 的方式不再有效，现在则需要改变为由某个第三方的数据库连接池的实现组件 （如 Apache 的 DBCP） 直接提供 DataSource。 此时，开发者需要如何修改以适应新的系统运行环境 的要求。 很简单，只需要修改 应用系统中的 DataSource 的配置为前面的 【例 13】中所示的配置效果。 从而使系统的 DAO组件可以在容器之内和容器之外自由地移植 和切换 ，从这个角度来看，系统的 DAO 组件是可重用的。 （ 2） 依赖注入机制 减轻了组件之间的依赖关系 回想传统 的编程技术中的 编码模式，如果要进行同样的修改 和满足同样的结果要求 ，开发者则需要付出比较大的努力 和编程修改的工作量。 因此，依赖注入机制减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，这意味着，组件得到重用的机 率将大杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料 杨教授工作室，版权所有，盗版必究 ， 13/22 页 大地提高。 Spring IOC 与工厂模式的对比 GOF 设计模式中的工厂模式也能够达到 类似 Spring IOC 的效果 （ 1） 应用 IOC 和 DI 的 设计理念 对 应用 系统带来 的 影响 将类之间的依赖关系转移到 应用系统的 外部配置文件中，从而避免在调用类中硬编码地 产生出实现类。 也就是 能够减少“服务的请求者”对“服务提供者”的特定实现逻辑的依赖。 （ 2）为达到上面相同的效果的常规开发实现方式 是利用 工厂模式 在以往的开发实现的技术中，通常是利用 GOF 设计模式中的工厂（ Factory）模式来解决此类问题。 利用工厂模式使外部调用类也就是客户端类不需要关心服务提供者的具体 实现，这样非常适合在同一个事物类型具有多种不同实现的情况下使。