应用层Spring框架技术及系统架构.doc

《应用层Spring框架技术及系统架构.doc》由会员分享，可在线阅读，更多相关《应用层Spring框架技术及系统架构.doc（21页珍藏版）》请在三一办公上搜索。

1、第1章 应用层Spring框架技术及系统架构Spring框架技术实际上是Rod Johnson在Expert One-on-One J2EE Design and Development一书中所阐述的设计思想的具体实现。Spring框架为J2EE平台的开发者提供的是一种“对象管理”技术，也就是为开发者解决包括 对象的生命周期、对象之间的依赖关系建立、对象的缓存实现等方面问题的管理技术。Spring框架是一个轻量级的控制反转（IoC）技术和面向切面编程（AOP）技术的容器框架，利用Spring框架中的IoC技术可以实现J2EE平台中所倡导的由容器实现对象的生命周期管理，而利用Spring 框架中

2、的AOP技术可以实现J2EE平台中所倡导的分离应用系统中业务逻辑组件和通用的技术服务组件。应用系统的开发者在应用系统中应用Spring框架后能够达到“解耦”和“脱离容器”的设计和实现的目的。本章重点介绍应用层Spring框架技术及系统架构，主要涉及Spring框架的特性、Spring框架的IoC和DI以及Spring IoC与GoF设计模式的工厂模式的对比；同时也还介绍Spring 框架的架构的特性以及Spring 框架的设计目标等方面的内容；最后再通过具体的应用示例实现，让读者体验Spring框架中IoC技术给应用系统的开发所带来的便利。1.1 应用层Spring框架技术1.1.1 Spri

3、ng框架的特性1关于Rod Johnson的Expert One-on-One J2EE Design andDevelopment一书1）Spring框架技术的起源Spring框架技术起源于Spring框架的主设计者Rod Johnson的Expert One-on-One J2EE Design and Development一书，此书已经由电子工业出版社出版，翻译版名为J2EE设计开发编程指南，参见图1.1中某图书网站对该书的简要介绍。图1.1 J2EE设计开发编程指南一书的简要介绍同时，一种新的Java框架技术Spring框架技术也相应发布，Spring框架技术也出自Rod Johns

4、on之手。2）Spring框架技术的产生Spring框架技术实际上是Rod Johnson在Expert One-on-One J2EE Design and Development一书中所阐述的设计思想的具体实现。在该书中，Rod Johnson 倡导J2EE实用主义的设计思想，并随书提供了一个初步的开发框架实现，也就是Interface21 开发软件包。Spring框架技术正是这一思想的全面和具体的体现。3）Spring框架的设计者Rod JohnsonRod Johnson 在Interface21开发包的基础之上，进行了进一步改造和扩充，使其发展成为一个更加开放、清晰、全面、高效的J2

5、EE平台中的应用层开发框架。2Spring框架属于应用层框架1）Spring框架提供的是一种“对象管理”技术在Spring框架中为应用系统的开发者提供的是“对象管理”技术，也就是为开发者解决包括对象的生命周期、对象之间的依赖关系建立、对象的缓存实现等方面问题的管理技术。而“对象管理”是每个面向对象编程的程序员都要面临的问题，将程序员从烦琐、单调和重复的编程工作中解脱出来，正是Spring框架的价值所在。2）Spring框架技术的目标是实现一个全方位的整合框架在Spring框架中包含有多个不同的子框架（或者称为组件），比如Spring AOP、Spring DAO、Spring ORM、Spri

6、ng Web和Spring MVC等。而这些子框架之间彼此可以独立，也可以使用其他的第三方框架方案替代其中的某个子框架。因为Spring框架采用的是分层设计的架构，这样将允许系统开发者独立地应用各个子框架来构建应用系统或者结合已有的其他框架共同构建应用系统。3传统的J2EE系统开发技术在现今的应用开发中所面临的问题1）J2EE技术及发展回顾J2EE技术平台的标准化特性大大提升了企业级应用系统开发的开放程度，并且得到了整个行业和众多上下游厂商、开发者的广泛认可。同时凭借Java语言所具有的平台无关性,对当时的企业级应用系统的开发产生了一定的促进作用。然而，J2EE在一些应用方面也表现出不尽如人意

7、之处，如低效、复杂以及依赖容器等导致应用系统的开发成本比较高、系统开发周期比较长。对J2EE平台的一些相关技术不满意的呼声也渐渐出现。2）J2EE技术平台（EJB）的主要问题 由于要采用多层架构设计和实现，因此如果应用系统设计不良好时，将导致系统编码实现比较复杂、单元测试比较难实施，并且无法有效控制开发周期。 由于可选择和可应用的相关技术太多，以及应用范围太大，而导致开发者在学习方面的成本比较高，需要系统地学习和掌握各个方面的相关知识，无法使初学者快速上手和迅速进入开发状态。 另外，早期的J2EE平台中的标准技术只注重中、大型企业级系统的应用开发和实现，而忽视小型系统的开发和实现的需求，不容易

8、开发和实现可伸缩性好的中、小型系统。合理并正确应用J2EE技术平台中的各个方面的应用技术来开发系统，其实并不是一件轻松的事情，因为开发者在应用某些具体的技术时需要仔细考虑和权衡各种技术的具体应用，以及应用某种技术后，可能会给应用系统带来的各种可能的负面作用。3）拒绝使用EJB组件技术并不意味着拒绝J2EE平台中一些良好的思想和解决方案J2EE平台下的企业级应用系统的开发者所要明确的是，拒绝使用EJB组件技术并不意味着拒绝J2EE平台中一些良好的解决方案和优秀的设计思想。比如，对象的生命周期管理、容器提供基础功能服务（达到分离应用组件和基础服务组件的思想）等。每个企业应用系统都需要这些基础服务。

9、但开发者应该如何利用现有的框架来提供这些基础服务以减轻企业在信息化系统建设方面投资的负担呢？伴随着这个问题的提出，一个轻量级的J2EE解决方案出现了：是否可以在轻量级平台中应用J2EE EJB组件中的各种核心技术？4利用Spring IoC和AOP实现J2EE EJB类似的主要技术Spring框架是一个轻量级的控制反转（IoC）技术和面向切面编程（AOP）技术的容器框架。在Spring框架技术中又是如何实现类似EJB组件的主要技术特性呢？1）标准J2EE技术平台中的主要的核心思想 容器实现对象的生命周期管理。 分离应用逻辑组件和通用服务组件。 应用服务器容器可以管理各个组件的事务并可以跨组件的

10、隔离（如EJB CMT 特性）。2）利用Spring框架中的IoC实现J2EE平台中所倡导的由容器实现对象的生命周期 管理 Spring框架技术中提供了IoC（控制反转）机制，借助于依赖注入设计模式，使得开发者不再需要自己来管理所依赖的目标对象自身的生命周期及其关系，这样能够改善开发者对J2EE和GoF设计模式中的各种模式的具体应用。 由于Spring IoC中所要求的JavaBean组件类为普通的Java类（Plain Ordinary Java Object，POJO），而不像EJB组件那样必须实现某个特定接口的要求，从而达到了轻量级的实现目标。3）利用Spring 框架中的AOP实现J2

11、EE平台中所倡导的分离应用逻辑组件和通用服务组件 借助于Spring框架技术中所提供的Spring AOP，能够达到类似“容器”提供基础功能服务的目标。 因为借助于Spring AOP中所提供的各种拦截器（Interceptor）和各种通知（Advice）技术，开发者能够实现以声明式的方式来使用企业级服务，比如安全性服务、事务服务、缓存服务等。在Spring框架中为什么要提供对AOP的具体实现？除了上述两个方面的目的以外，还允许用户实现自定义的切面功能，用Spring AOP中所提供的各种类型的通知和拦截器来进一步完善面向对象的编程（OOP）技术的应用。4）Spring IoC和 Spring

12、 AOP组合在一起形成了完整的Spring框架技术没有Spring IoC的Spring AOP是不完整的，当然没有Spring AOP的Spring IoC，其最终的结果将是不健壮的。因此，可以这样认为：Spring框架 = IoC + AOP。5基于Spring框架的应用系统开发所体现出的主要的优点：“解耦”和“脱离容器”1）对于系统设计者能够在设计方面达到“松耦合”的系统设计目标（1）“松耦合”的系统设计目标。“松耦合”的系统设计一方面主要体现在应用系统中的各个部分之间（包括应用系统的核心类代码之间、应用系统与其所在的框架平台之间）尽量形成一种松耦合的结构，这使得应用系统具有更好的灵活性

13、和可扩展性；另一方面也体现在应用系统与其所在的底层应用服务器平台的解耦上。（2）在Spring框架中如何实现上面两种形式的解耦。应用系统内部的类之间的解耦主要通过一种称为控制反转（IoC）的技术来实现，应用系统与底层应用服务器平台的解耦则是借助其所提供的Spring AOP技术来实现。因为 在Spring框架中内置了对AOP的具体实现，这将使得一些本来必须由J2EE应用服务器容器所支持的功能，比如事务管理控制、安全管理和身份验证等方面的技术实现可以脱离J2EE 应用服务器容器而能够在容器外的普通Java虚拟机（JVM）环境中运行。 2）对于系统实现者能够简化J2EE平台中的一些复杂的应用实现技

14、术, 并养成“面向接口编程实现”的良好的编程习惯 利用其对象“延时依赖注入”思想组装代码和建立代码之间的关系，这样一方面减少了在使用这些对象的客户程序中的大量代码，另一方面也提高应用系统的扩展性和灵活性，最终真正地实现插件式编程和开发实现。 利用Spring框架对AOP的具体支持，达到集中处理应用系统中的业务逻辑并分离附加技术支持和实现的代码，从而减少代码的重复以构建出简洁和优雅的解决 方案。 利用Spring框架对其他框架的支持，比如对Hibernate的SessionFactory组件、事务管理等方面的封装，更简洁地应用和集成Hibernate等O/R Mapping框架和其他的框架技术（

15、如Struts等）。3）如果开发者不应用Spring框架及其各个相关的组件，将额外需要编程实现许多 代码同时这些代码与由Spring框架提供的功能相比效果又怎样？比如事务处理、JDBC数据库访问等实现。可能会出现“花了精力但效果不好”的局面。根据AOP中所倡导的分离应用系统中的核心关注点和横切关注点的基本原则，计算 机的应用开发者应该更多地把主要精力放在应用系统的业务逻辑功能的实现方面，以便交付出有业务价值的信息化系统；而不应该过多地花费时间和精力来解决普通的计算机应用中的技术问题，如事务管理、安全管理、对象缓存和数据库连接池等技术的实现。1.1.2 Spring框架中的IoC和DI1Spri

16、ng框架中的IoC1）控制反转（Inversion of Control，IoC）所谓控制反转，就是将应用系统中原来由程序控制“对象之间的关系”转交给由外部容器来实现控制。借助于控制反转的机制，能够实现由容器控制程序中的各个类之间的关系，而非传统形式的编程实现中直接在程序代码中由程序代码操控各个类对象实例之间的关系。这就是“控制反转”的概念：控制权由应用系统中的程序代码转移到了外部容器。控制权的转移，即“控制反转”；利用“控制反转”能够减少对象的请求者对服务提供者的特定实现逻辑的依赖，因为应用系统中的各个组件类不再需要去查找或是实例化它们所依赖的其他目标组件类。2）IoC是一种使应用程序逻辑外

17、在化的设计模式在这种编程模式下，提供服务的目标组件是被“注入”的而不是被“直接写入”到请求者（客户端）的代码中；这样将大大减少对象的请求者对服务提供者的特定实现逻辑的依赖。因为开发者已经将依赖的具体“定位信息”和“关系信息”从请求者中分离出来了，而在Spring框架中则是将它们放在IoC的*.XML的配置文件中。3）应用Spring 框架中的IoC进行系统开发时的基本要求为了能够更好地应用Spring框架中的IoC技术，对开发者在具体编程方面也有一定的要求。也就是在代码中不应该再直接创建出目标对象的实例，而应该只描述出创建它们的方式。即在代码中不直接与服务对象连接，但需要在配置文件（一般为*.

18、XML文件）中描述出应用系统中的哪一个功能组件需要哪一项服务。应用系统中的组件类程序在运行时，由容器（在 Spring 框架中是指 IoC 容器）负责将这些对象关联在一起，并依据调用关系将目标对象注入。4）应用Spring框架中的IoC的代码示例在下面的Spring框架中的IoC的*.XML文件的示例中声明了两个对象，名称分别为theUpperAction和theLowerAction。在运行过程中，由Spring框架中的IoC容器并分别为该两个对象动态注入属性字符串值。请参见【例1-1】中的代码，并请注意其中黑体部分的代码。 1-1 应用Spring框架中的IoC容器的代码示例。 HeLLo

19、,UpperAction 它会被动态地注入到UpperTrnsferAction的messageProperty属性中 HeLLo,LowerAction 它会被动态地注入到LowerTrnsferAction的messageProperty属性中 2Spring 框架中的依赖注入DI技术1）依赖注入（Dependency Injection，DI）是对IoC的另一种描述当初Rod Johnson提出IoC的概念时，曾经引起业界的争论。因为在 IoC的概念中没有具体说明如何实现控制反转、反转给谁以及在什么时候进行控制反转等方面的问题。正在业界为IoC的概念争论不休时，大师级人物Martin F

20、owler发表了一篇经典文章Inversion of Control Containers and the Dependency Injection pattern为IoC正名，至此，IoC又获得了一个新的名字依赖注入（Dependency Injection）。Dependency Injection是依赖注入的意思，也就是将应用系统中的各个类之间的依赖关系先剥离（也就是常说的解耦或者分离），然后在应用系统运行过程中根据应用之间的调用关系再适时地注入到目标系统中。2）什么是依赖注入根据上面的说明，相对于IoC 而言，“依赖注入”更加准确地描述了IoC的设计理念。从名字上来直接理解，所谓依赖注

21、入，即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。Computer 与CPU和HardDisk之间为组合关系 1-2 类之间的各种关系的示例。Computer 与Print之间为聚合关系class Computer private CPU intelCPU=null;Computer 与UserInfo之间为“一对一”的关联关系 private List someHardDis=null; private Printer hpPrinter=null; private UserInfo oneUserInf

22、o=null; public Result calculate(Data oneData)Computer 与Data之间为“依赖”关系 class CPU class HardDisk class Printer class UserInfo 【例1-2】 中给出了计算机Computer类与其他各个类之间的各种关系的示例。在传统的应用开发中，需要开发者自己在Computer类中分别创建出各个依赖的目标类的对象实例，如CPU和Printer类对象等，这样将使得Computer类与它所依赖的各个目标类之间产生紧密耦合关系。3）IoC和DI的本质都是改变依赖关系组件类和组件类之间的关系依赖由原来的

23、依赖“目标组件”改变为现在的依赖于“IoC容器”。为什么要进行如此的改变？（1）为什么不应该直接依赖应用系统中的“目标组件”？依赖在应用系统中是客观存在的，如果应用系统中不存在依赖关系，就意味着应用系统是由各个相互孤立的模块或者组件所构成，这是无法构成一个相互协作和互相配合的有机整体的。问题是应该依赖谁? 根据Spring框架中的 IoC的设计原理，应用系统中的某个组件类应该依赖所在的上层容器而不要直接依赖目标组件类。主要是由于目标组件类有可能会随着应用系统的需求变化而经常会发生改变和调整，开发者当然也不希望在应用系统中由于某个“方面”发生改变而相关联的各个组件类也必须随之改变！J2EE平台中

24、倡导多层架构中分层的目的也就是希望能够取得良好的隔离效果。（2）为什么可以依赖于“IoC容器（Spring框架）”？由于容器相对于应用系统本身而言应该是相对稳定的，不会频繁发生改变（当然，Spring框架本身也会发生升级改变）。这样，也就达到了将应用系统中的“可变”和“不变”部分相互分离的目的。3在Spring框架中提出“依赖注入”的设计理念1）主要目的软件系统开发中的各种理论、思想包括软件工程等都一直在提倡“软件重用”，但问题是如何能够重用？以及采用什么样的具体实现方法? Spring框架中所提出的“依赖注入”的设计理念为“软件重用”的真正实现带来了可操作的实现方法。依赖注入的目标并非为软件

25、系统带来更多的功能，应用它的目的是为了提升“组件重用”的概率，同时也为应用系统搭建出一个更加灵活的、可扩展的平台。因为，现在的企业级应用系统的开发更加注重系统的安全性、稳定性、可扩展性和可移植性等目标。2）应用依赖注入的设计理念在系统架构设计方面所产生的效果提高了组件的可移植性和可重用度，依赖注入机制减轻了组件之间的依赖关系，因为目标对象的创建并不是在源组件类中直接以编码方式产生的，这也是遵守J2EE平台倡导的“松耦合”的系统开发要求的。3）应用依赖注入的设计理念在系统开发实现方面所产生的效果能够更简洁地编程应用J2EE平台中的各种复杂的技术实现，并使应用系统具有良好的可扩展性和灵活性。下面通

26、过一个在应用系统的持久层开发实现中DAO组件中应用DataSource实现数据库连接的示例，来说明Spring框架中的依赖注入是如何简化系统开发实现的。 1-3 某个DAO组件获得DataSource对象从而获得数据库连接对象的示例。 com.microsoft.jdbc.sqlserver.SQLServerDriver BasicDataSource是Apache的DBCP数据库连接池的实现 jdbc:microsoft:sqlserver:/localhost:1433;DatabaseName=定义出目标数据库的连接参数及账号 WebStudyDB sa 1234 定义出目标DAO组件

27、对象 目标DAO组件对象所在的类 将前面的dataSource对象以属性注入的方式注入到本DAO组件中 上面的示例是将Apache DBCP的数据库连接池的实现类BasicDataSource的对象实例注入到应用系统的DAO组件中，从而避免由应用系统的开发者自己编程实现基于JDBC 2.0的DataSource接口的实现。我们知道，对于数据库连接池的具体编程实现不是所有的开发者都有能力完成的，因为它要考虑许多开发和线程同步等方面的技术，这是有一定的技术复杂性和难度的。4）在系统的可维护性方面所产生的效果提高了应用系统的可移植性和可维护性。当应用系统中的某一环境参数发生变化，并不需要大量地修改程

28、序中的代码，而只需要调整配置文件及配置文件中的参数。比如对于【例1-3】中的示例，如果应用系统的数据库连接池是在应用系统的部署环境中实现的，那么最终实际是采用应用容器的JNDI形式的数据库连接池的实现方案，此时只需要更新DataSource对象的实例的定义，而不需要修改应用系统中的DAO组件中的有关代码。请见下面如【例1-4】所示的最后修改结果。 1-4 应用容器的JNDI数据库连接池的实现的示例，请注意其中黑体部分的代码。连接池的实现交给容器 java:/comp/env/jdbc/dataSource 在容器中所定义出的连接池的dataSource名称 其中UserInfoDAOBean组

29、件假设是一个运行在J2EE应用服务器容器，如Weblogic或者Tomcat等中的组件，而DataSource是由J2EE应用服务器容器所创建的。系统中的DAO组件在运行过程中将由Spring IoC容器动态注入，而DataSource的具体配置和初始化工作也将由IoC容器在运行期完成。因此，从上面的两个示例的最终实现，对比传统的如通过编码初始化DataSource对象实例的实现方式，基于依赖注入的系统实现是相当灵活和简洁的。4从上面的示例所反映出的编程实现的效果通过依赖注入机制，开发者只需要通过简单地配置，无须任何编程实现代码就可在应用系统的UserInfoDAOBean组件中获得所需要的D

30、ataSource对象实例。也就是说，UserInfoDAOBean组件的开发者只需利用容器注入的DataSource对象实例，完成自身的数据访问的各种CRUD的访问逻辑，而不用关心应用系统中后台具体的数据源来自何处、采用什么形式的具体技术实现等方面的问题。1）提高了组件的可移植性和可重用度假设应用系统的部署环境发生了变化，应用系统的持久层中的各种形式的DAO组件需要脱离应用服务器容器（在容器之外）独立运行。由于失去了容器的支持，原本通过JNDI获取DataSource的方式不再有效，现在则需要改变为由某个第三方的数据库连接池的实现组件（如Apache 的DBCP）直接提供DataSource

31、。此时，开发者需要如何进行修改以适应新的系统运行环境的要求？很简单，只需要修改应用系统中的DataSource的配置为如【例1-3】所示的配置效果。从而使系统的DAO组件可以在容器之内和容器之外自由地移植和切换。从这个角度来看，系统的DAO组件是可重用的。2）依赖注入机制减轻了组件之间的依赖关系回顾传统的编程技术中的编码模式，如果要进行同样的修改和满足同样的结果要求，开发者则需要付出比较多的努力，完成大量编程修改工作。因此，依赖注入机制减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，这意味着，组件得到重用的几率将大大提高。1.1.3 Spring IoC与工厂模式的对比1GoF设计模

32、式中的工厂模式也能够达到类似Spring IoC的效果1）应用IoC和DI的设计理念对应用系统带来的影响 将类之间的依赖关系转移到应用系统的外部配置文件中，从而避免在调用类中以硬编码方式产生出实现类。也就是能够减少“服务请求者”对“服务提供者”的特定实现逻辑的依赖。2）为达到上面相同的效果的常规开发实现方式是利用工厂模式在以往的开发实现的技术中，通常是利用GoF设计模式中的工厂（Factory）模式来解决此类问题。利用工厂模式使外部调用类也就是客户端类不需要关心服务提供者的具体实现，这非常适合在同一个事物类型具有多种不同实现的情况下使用，以隔离对象的创建者和对象的使用者。2利用工厂模式分离在创

33、建对象方面的依赖关系为了能够让读者了解为什么要应用工厂模式，以及应用工厂模式给应用系统所带来的效果。下面通过一个示例的演变过程来加以说明，并考察一个UserManagerImple类和MySQLDAOInterfaceImple类的依赖关系。1）两个类之间直接产生依赖关系【例1-5】中的用户管理类UserManagerImple及其对应的DAO组件MySQLDAO- InterfaceImple类之间直接产生依赖关系。 1-5 两个类之间直接产生依赖关系的代码示例，请注意其中黑体部分的代码。package com.px1987.springwebapp.model;import com.px1

34、987.springwebapp.dao.*;public class UserManagerImple implements UserManagerInterface MySQLDAOInterfaceImple daoOperatorDBBean=null;public UserManagerImple() public boolean doUserLogin(UserInfoVO oneUserInfo)daoOperatorDBBean=new MySQLDAOInterfaceImple();String userName=oneUserInfo.getUserName();Stri

35、ng userPassWord=oneUserInfo.getUserPassWord(); boolean okOrNot=false;UserInfoVO returnOneUserInfo= daoOperatorDBBean.getOneUserInfo(userName,userPassWord);if(returnOneUserInfo=null)okOrNot = false;else okOrNot = true;return okOrNot;从上面的代码示例可以看出，UserManagerImple类直接依赖于MySQLDAO- InterfaceImple类，这个依赖关系意

36、味着当MySQLDAOInterfaceImple类修改时或者被替换为其他类型的DAO组件时，UserManagerImple类也会受到影响。同时也违反Robert C. Martin在其敏捷软件开发中所描述的依赖倒置原则（Dependency Inversion Principle, DIP），“高层模块不应该依赖于低层模块，两者都应该依赖于抽象；抽象不应该依赖于具体实现，细节应该依赖于抽象”。2）利用接口来消除UserManagerImple类对MySQLDAOInterfaceImple类的直接依赖关系 1-6 利用DAO组件的接口DAOInterface来隔离两者之间的依赖关系的代码示

37、例， 请注意其中黑体部分的代码。package com.px1987.springwebapp.model;import com.px1987.springwebapp.dao.*;public class UserManagerImple implements UserManagerInterface DAOInterface daoOperatorDBBean=null;public UserManagerImple() public boolean doUserLogin(UserInfoVO oneUserInfo)daoOperatorDBBean=new MySQLDAOInter

38、faceImple();String userName=oneUserInfo.getUserName();String userPassWord=oneUserInfo.getUserPassWord(); boolean okOrNot=false;UserInfoVO returnOneUserInfo= daoOperatorDBBean.getOneUserInfo(userName, userPassWord);if(returnOneUserInfo=null) okOrNot = false;else okOrNot = true;return okOrNot;经过这样的优化设

39、计后，虽然其中的UserManagerImple和MySQLDAOInterfaceImple两者之间不再存在直接的依赖关系，但是UserManagerImple和MySQLDAOInterfaceImple类之间还是在对象创建方面存在依赖关系。为了解决这种对象创建方面的依赖关系，经典的GoF设计模式中提供了工厂（Factory）模式，将对象的创建交给工厂模式中的工厂类来创建。从而也能够达到隔离对象的创建者和对象的使用者的效果。3用工厂模式来实现类似IoC效果的示例根据GoF设计模式中的工厂模式的编程规则，需要定义出下面的各个角色：产品类的接口、产品类的接口的实现、工厂类和调用者客户类。当然，

40、关于工厂模式的更进一步的说明参见本书第11章。1）产品的接口定义【例1-7】中的DAOInterface.java代码代表应用系统中的DAO接口（也就是工厂模式中的某种产品类的接口，它代表所要创建的对象应该具有的功能要求定义）。 1-7 工厂模式中的产品类（DAO 接口DAOInterface）的接口代码示例。 package com.px1987.springwebapp.dao;import java.sql.*;import com.px1987.springwebapp.model.*;public interface DAOInterface public UserInfoVO getOneUserInfo(String userName,String userPassWord);