J2EE项目实训 Spring框架技术——第1章 应用层Spring框架技术及系统架构（第1部分）

1、杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料第1章 应用层spring框架技术及系统架构（第1/2部分）spring框架技术实际上是rod johnson在expert one-on-one j2ee design and development一书中所阐述的设计思想的具体实现。spring框架为j2ee平台的开发者提供的是一种“对象管理”的技术，也就是为开发者解决包括对象的生命周期、对象之间的依赖关系建立、对象的缓存实现等方面的管理技术。spring框架是一个轻量级的控制反转技术（ioc）和面向切面编程（aop）技术的容器框架，利用spring框架中的ioc技术可以实现j2ee平

2、台中所倡导的由容器实现对象的生命周期管理，而利用spring 框架中的aop技术可以实现j2ee平台中所倡导的分离应用系统中业务逻辑组件和通用的技术服务组件。应用系统的开发者在应用系统中应用spring框架后能够达到“解耦”和“脱离容器”的设计和实现的效果。本章将重点介绍应用层spring框架技术及系统架构，主要涉及spring框架的特性、spring框架中的ioc和di以及spring ioc与gof设计模式中的工厂模式的对比；同时也还将介绍spring 框架的架构的特性以及spring 框架的设计目标等方面的内容；最后再通过具体的应用示例实现，让读者体验spring框架中的ioc技术给应用

3、系统的开发所带来的优点。1.1 应用层spring框架技术1.1.1 spring框架的特性1、关于rod johnson 的expert one-on-one j2ee design and development一书（1）spring框架技术的起源spring框架技术起源于spring框架的主设计者rod johnson的expert one-on-one j2ee design and development一书，此书已经由电子工业出版社出版，翻译版名为j2ee设计开发编程指南，参见图1.1中某图书网站对该书的简要介绍。同时一个新的java框架技术 spring框架技术也相应地发布出，同

4、样也出自rod johnson之手。图1.1 译版名为j2ee设计开发编程指南一书简要介绍（2）spring框架技术的产生spring框架技术实际上是rod johnson在expert one-on-one j2ee design and development一书中所阐述的设计思想的具体实现。在该书中，rod johnson 倡导j2ee 实用主义的设计思想，并随书提供了一个初步的开发框架实现，也就是interface21 开发软件包。spring框架技术正是这一思想的全面和具体的体现。（3）spring框架的设计者rod johnsonrod johnson 在interface21开发

5、包的基础之上，进行了进一步改造和扩充，使其发展成为一个更加开放、清晰、全面、高效的j2ee平台中的应用层的开发框架。2、spring框架属于应用层的框架（1）spring框架提供的是一种“对象管理”的技术在spring框架中为应用系统的开发者提供的是“对象管理”技术，也就是为开发者解决包括对象的生命周期、对象之间的依赖关系建立、对象的缓存实现等方面的管理技术。而“对象管理”技术是每个面向对象编程的程序员都要面临的问题,将程序员从烦琐、单调和重复的编程中解脱出来，正是spring框架的价值所在。（2）spring框架技术的目标是实现一个全方位的整合框架在spring框架中包含有多个不同的子框架（

6、或者称为组件），比如spring aop、spring dao 和spring orm、spring web和spring mvc等。而这些子框架之间彼此可以独立，也可以使用其它的第三方的框架方案替代其中的某个子框架。因为spring框架采用的是分层设计的架构，这样将允许系统开发者可以独立地应用各个子框架来构建应用系统或者结合已有的其他框架共同构建应用系统。3、传统的j2ee系统开发技术在现今的应用开发中所面临的问题（1）j2ee技术及发展的回顾j2ee技术平台的标准化的特性大大提升了企业级应用系统开发的开放程度，并且得到了整个行业和众多上下游厂商、开发者的广泛认可。同时凭借java语言所具有

7、的平台无关性,对当时的企业级应用系统的开发产生了一定的促进作用。然而，j2ee在一些应用方面也表现出不尽人意之处，如低效、复杂以及依赖容器等导致应用系统的开发成本比较高、系统的开发周期比较长。对j2ee平台中的一些相关技术的不满意的呼声也渐渐出现。（2）j2ee技术平台（ejb）的主要问题1) 由于要采用多层架构设计和实现，因此如果应用系统设计不良好时，将导致系统编码实现比较复杂、单元测试比较难实施，并且无法有效控制开发周期。2) 由于可选择和可应用的相关技术太多以及应用范围太大，而导致开发者在学习方面的成本比较高，需要系统地学习和掌握各个方面的相关知识，无法使初学者快速上手和迅速进入开发状态

8、。3) 另外，早期的j2ee平台中的标准技术只注重中、大型企业级系统的应用开发和实现，而忽视小型系统的开发和实现的需求，不容易开发和实现可伸缩性好的中、小型系统。合理并正确应用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、平台中的主要的核心思想1) 容器实现对象的生命周期管理2) 分离应用逻辑组件和通用服务组件3) 应用服务器容器可以管理各个组件的事务并可以跨组件的隔离（如ejb cmt特性）（2）利用spring框架中的ioc实现j2ee平台中所倡导的由容器实现对象的生命周期管理1) spring 框架技术中提供了ioc（控制反转），借助于依赖注入设计模式，使得开发者不再需要自己来管理所依赖的目标对象自身的生命周期及其关系，这样能够改善开发者对j2ee和gof设计模式中的各种模式的具体应用。2) 由于spring ioc中所要求的javabean组件类为普通的java类(plain ordinary java

11、 object，pojo)，而不象ejb组件那样的必须实现某个特定接口的要求。从而达到轻量级的实现目标。（3）利用spring 框架中的aop实现j2ee平台中所倡导的分离应用逻辑组件和通用服务组件1) 借助于spring框架技术中所提供的spring aop，从而能够达到类似“容器”提供基础功能服务的目标。2) 因为借助于spring aop中所提供的各种拦截器（interceptor）和各种通知（advice）技术，开发者能够实现以声明式的方式来使用企业级服务，比如安全性服务、事务服务、缓存服务等。当然，在spring框架中为什么要提供对aop的具体实现，除了上面的两个方面的目的以外，还允

12、许用户实现自定义的切面功能，用spring aop中所提供的各种类型的通知和拦截器来进一步地完善面向对象的编程技术（oop）的应用。（4）spring ioc和 spring aop组合在一起形成了完整的spring框架技术没有spring ioc的spring aop是不完善的，当然没有spring aop的spring ioc，其最终的结果将是不健壮的。因此，可以这样认为：spring框架 =ioc + aop。5、基于spring框架的应用系统开发所体现出的主要的优点：“解耦”和“脱离容器”（1）对于系统设计者能够在设计方面达到“松藕合”的系统设计目标l “松藕合”的系统设计目标“松藕合

13、”的系统设计一方面主要体现在应用系统中的各个部分之间（包括应用系统的核心类代码之间、应用系统与其所在的框架平台之间）尽量形成一种松耦合的结构，这使得应用系统具有更好的灵活性和可扩展性；另一方面也体现在应用系统与其所在的底层应用服务器平台的解耦。l 在spring框架中是如何实现上面的两种形式的解耦应用系统内部的类之间的解耦主要通过一种称为控制反转（ioc）的技术来实现；应用系统与底层应用服务器平台的解耦则是借助其所提供的spring aop技术来实现，因为在spring框架中内置了对aop的具体实现，这将使得一些本来必须由j2ee 应用服务器容器所支持的功能，比如事务管理控制、安全管理和身份验

14、证等方面的技术实现可以脱离j2ee 应用服务器容器而能够在容器外的普通的java虚拟机（jvm）环境中运行。 （2）对于系统实现者能够简化j2ee平台中的一些复杂的应用实现技术, 并养成“面向接口编程实现”的良好的编程习惯1) 利用其对象“延时依赖注入”思想组装代码和建立代码之间的关系，这样一方面减少了在使用这些对象的客户程序中的大量代码，另一方面也提高应用系统的扩展性和灵活性，最终真正地实现插件式编程和开发实现；2) 利用spring框架 对aop的具体支持，达到集中处理应用系统中的业务逻辑并分离附加技术支持和实现的代码，从而减少代码的重复以构建出简洁和优雅的解决方案；3) 利用spring

15、框架对其它框架的支持，比如对hibernate的sessionfactory组件、事务管理等方面的封装，更简洁地应用和集成hibernate等o/r mapping框架和其它的框架技术（如struts等）。（3）如果开发者不应用spring框架及其各个相关的组件，将额外需要编程实现许多代码!当然，如果开发者在应用开发的过程中，不应用spring框架技术，将额外需要编程实现许多代码！同时这些代码跟由spring框架提供的功能相比效果又怎样？比如事务处理、jdbc数据库访问等实现。可能会出现“花了精力但又效果不好”局面。根据aop中所倡导的分离应用系统中的核心关注点和横切关注点的基本原则，计算机的

16、应用开发者更多地应该把主要的开发精力放在应用系统的业务逻辑功能的实现方面从而能够交付出有业务价值的信息化系统，而不应该去过多地花费时间和精力来解决普通的计算机应用中的技术问题。如事务管理、安全管理、对象缓存和数据库连接池等技术的实现。1.1.2 spring框架中的ioc和di1、spring框架中的ioc（1）控制反转ioc（inversion of control）所谓的控制反转，就是将应用系统中原来由程序控制“对象之间的关系”转交给由外部容器来实现控制。借助于控制反转的机制，能够实现由容器来控制程序中的各个类之间的关系，而非传统形式的编程实现中直接在程序代码中由程序代码来操控各个类对象实

17、例之间的关系。这也就是“控制反转”的概念所在：控制权由应用系统中的程序代码转移到了外部容器。控制权的转移，也就是所谓的“控制反转”；当然，利用“控制反转”能够减少对象的请求者对服务提供者的特定实现逻辑的依赖，因为应用系统中的各个组件类不再需要去查找或是实例化它们所依赖的其它的目标组件类。（2）ioc 是一种使应用程序逻辑外在化的设计模式因为在这种编程模式下，提供服务的目标组件是被“注入”的而不是被“直接写入”到请求者（客户端）的代码中；这样将能够大大地减少对象的请求者对服务提供者的特定实现逻辑的依赖。因为开发者已经将依赖的具体“定位信息”和“关系信息”从请求者中分离出来了，而在spring框架

18、中则是将它们放在ioc的*.xml的配置文件中。（3）应用spring 框架中的ioc进行系统开发时的基本要求为了能够更好地应用spring框架中的ioc技术，当然对开发者在具体编程方面也有一定的要求。也就是在代码中不应该再直接创建出目标对象的实例，而应该只描述出创建它们的方式。即在代码中不直接与服务对象连接，但需要在配置文件（一般为*.xml文件）中描述出应用系统中的哪一个功能组件需要哪一项服务。应用系统中的组件类程序在运行时，由容器 （在 spring 框架中是指 ioc 容器）负责将这些对象关联在一起，并依据调用关系将目标对象注入。（4）应用spring框架中的ioc的代码示例在下面的s

19、pring框架中的ioc的*.xml文件的示例中，声明了两个对象，名称分别为theupperaction和theloweraction；在运行过程中由spring框架中的ioc容器并分别为该两个对象动态注入属性字符串值。请见下面的【例1-1】中的代码所示，并请注意其中的黑体部分的代码。【例1-1】应用spring框架中的ioc容器的代码示例hello,upperaction hello,loweraction 2、spring 框架中的依赖注入di技术（1）依赖注入di（dependency injection） 是对ioc的另一种描述当初rod johnson提出ioc的概念时，曾经引起业界

20、为此争论。因为在 ioc的概念中没有具体说明如何实现控制反转、反转给谁以及在什么时候进行控制反转等方面的问题。正在业界为ioc的概念争论不休时，大师级人物martin fowler发表了一篇经典文章inversion of control containers and the dependency injection pattern为ioc正名，至此，ioc又获得了一个新的名字：“依赖注入（dependency injection）”。“dependency injection”是依赖注入的意思，也就是将应用系统中的各个类之间的依赖关系先剥离（也就是常说的解藕或者分离），然后在应用系统运行过程

21、中根据应用之间的调用关系适时地再注入到目标系统中。（2）什么是依赖注入根据上面的说明，因此相对于ioc 而言，“依赖注入”更加准确地描述了ioc的设计理念。从名字上来直接理解，所谓的依赖注入，即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。【例1-2】 类之间的各种关系的示例class computer private cpu intelcpu=null;private list someharddis =null; private printer hpprinter =null;private userin

22、fo oneuserinfo=null;public result calculate(data onedata)class cpu class harddisk class printer class userinfo 在上面的【例1-2】中给出计算机computer类与其它的各个类之间的各种关系的示例，在传统的应用开发中，是需要开发者自己在computer类中分别创建出各个依赖的目标类的对象实例如cpu和printer类对象等。这样将使得computer类与它所依赖的各个目标类之间产生紧密藕合关系。（3）ioc和di的本质都是改变依赖关系 组件类和组件类的之间的关系的依赖由原来的依赖“目标

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

24、平台中倡导多层架构中分层的目的也就是希望能够达到良好的隔离。l 哪又为什么可以依赖于“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 jdbc:microsoft:sqlserver:/localhost:1433;databasename=webstudydb sa 1234 上面的示例是将apache的dbcp的数据库连接池的实现类basicdata

27、source的对象实例注入到应用系统的dao组件中，从而可以避免由应用系统的开发者自己编程实现基于jdbc 2.0的datasource接口的实现。读者应该知道，对于数据库连接池的具体编程实现也不是所有的开发者都有能力能够编程实现的，因为它要考虑许多并发和线程等同步方面的技术，应该是有一定的技术的复杂性和难度的。（4）在系统的可维护性方面所产生的效果提高了应用系统的可移植性和可维护性，当应用系统中的某一环境参数发生变化，并不需要大量地修改程序中的代码，而只需要调整一下配置文件及配置文件中的参数。比如对于【例1-3】中的示例，如果应用系统的数据库连接池的实现在应用系统的部署环境中，最终实际是采用

28、应用服务器容器的jndi形式的数据库连接池的实现方案，此时只需要更新datasource对象的实例的定义，而不需要修改应用系统中的dao组件中有关的代码。请见下面的【例1-4】中所示的最后修改的结果。【例1-4】 应用容器的jndi数据库连接池的实现的示例，并请注意其中的黑体部分的内容。 java:/comp/env/jdbc/datasource 其中userinfodaobean组件假设是一个运行在j2ee应用服务器容器如weblogic或者tomcat等中的组件，而datasource是由j2ee应用服务器容器所创建的。当系统中的dao组件在运行过程中将由spring ioc容器动态注入

29、，而datasource的具体配置和初始化工作也将由ioc容器在运行期完成。因此，从上面的两个示例的最终的实现，对比传统的如通过编码初始化datasource对象实例的实现方式，基于依赖注入的系统实现是相当灵活和简洁的。4、从上面的示例所反映出的编程实现的效果通过依赖注入的机制，开发者只需要通过简单地配置，而无需任何编程实现代码就可在应用系统的userinfodaobean组件中获得所需要的datasource对象实例。也就是userinfodaobean组件的开发者只需利用容器注入的datasource对象实例，完成自身的数据访问的各种crud的访问逻辑，而不用关心应用系统中后台具体的数据源

30、来自何处、采用什么形式的具体技术实现等方面的问题。（1）提高了组件的可移植性和可重用度假设应用系统的部署环境发生了变化，应用系统中的持久层中的各种形式的dao组件需要脱离应用服务器容器而在容器之外独立运行。由于失去了容器的支持，原本通过jndi获取datasource的方式不再有效，现在则需要改变为由某个第三方的数据库连接池的实现组件（如apache 的dbcp）直接提供datasource。此时，开发者需要如何修改以适应新的系统运行环境的要求？很简单，只需要修改应用系统中的datasource的配置为前面的【例1-3】中所示的配置效果。从而使系统的dao组件可以在容器之内和容器之外自由地移植

31、和切换，从这个角度来看，系统的dao组件是可重用的。（2）依赖注入机制减轻了组件之间的依赖关系回想传统的编程技术中的编码模式，如果要进行同样的修改和满足同样的结果要求，开发者则需要付出比较大的努力和编程修改的工作量。因此，依赖注入机制减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，这意味着，组件得到重用的机率将大大地提高。1.1.3 spring ioc与工厂模式的对比1、gof设计模式中的工厂模式也能够达到类似spring ioc的效果（1）应用ioc和di的设计理念对应用系统带来的影响 将类之间的依赖关系转移到应用系统的外部配置文件中，从而避免在调用类中硬编码地产生出实现类。也就

32、是能够减少“服务的请求者”对“服务提供者”的特定实现逻辑的依赖。（2）为达到上面相同的效果的常规开发实现方式是利用工厂模式在以往的开发实现的技术中，通常是利用gof设计模式中的工厂（factory）模式来解决此类问题。利用工厂模式使外部调用类也就是客户端类不需要关心服务提供者的具体实现，这样非常适合在同一个事物类型具有多种不同实现的情况下使用，隔离对象的创建者和对象的使用者。 2、利用工厂模式分离在创建对象方面的依赖关系为了能够让读者了解为什么要应用工厂模式，以及应用工厂模式给应用系统所带来的效果。下面通过一个示例的演变过程来加以说明，并考察一个usermanagerimple类和mysqld

33、aointerfaceimple类的依赖关系。（1）两个类之间直接产生依赖关系下面的【例1-5】中的用户管理类usermanagerimple和其对应的dao组件mysqldaointerfaceimple类之间直接产生依赖关系。【例1-5】两个类之间直接产生依赖关系的代码示例，并注意其中的黑体部分的代码package com.px1987.springwebapp.model;import com.px1987.springwebapp.dao.*;public class usermanagerimple implements usermanagerinterface mysqldaoin

34、terfaceimple daooperatordbbean=null;public usermanagerimple() public boolean douserlogin(userinfovo oneuserinfo)daooperatordbbean=new mysqldaointerfaceimple();string username=oneuserinfo.getusername();string userpassword=oneuserinfo.getuserpassword(); boolean okornot=false;userinfovo returnoneuserin

35、fo=daooperatordbbean.getoneuserinfo(username, userpassword);if(returnoneuserinfo=null)okornot = false;else okornot = true;return okornot;从上面的代码示例中，可以看出usermanagerimple类直接依赖于mysqldaointerfaceimple类，这个依赖关系意味着当mysqldaointerfaceimple类修改时或者被替换为其它类型的dao组件，usermanagerimple类也会受到影响。同时也违反robert c. martin在其敏捷软

36、件开发中所描述的依赖倒置原则（dependency inversion principle, dip），“高层模块不应该依赖于低层模块，两者都应该依赖于抽象；抽象不应该依赖于具体实现，细节应该依赖于抽象”。（2）利用接口来消除usermanagerimple类对mysqldaointerfaceimple类的直接依赖关系【例1-6】利用dao组件的接口daointerface来隔离两者之间的依赖关系的代码示例，请读者仍然注意其中的黑体部分的代码package com.px1987.springwebapp.model;import com.px1987.springwebapp.dao.*;p

37、ublic class usermanagerimple implements usermanagerinterface daointerface daooperatordbbean=null;public usermanagerimple() public boolean douserlogin(userinfovo oneuserinfo)daooperatordbbean=new mysqldaointerfaceimple();string username=oneuserinfo.getusername();string userpassword=oneuserinfo.getuse

38、rpassword(); boolean okornot=false;userinfovo returnoneuserinfo=daooperatordbbean.getoneuserinfo(username, userpassword);if(returnoneuserinfo=null) okornot = false;else okornot = true;return okornot;经过这样的优化设计后，虽然其中的usermanagerimple和mysqldaointerfaceimple两者之间不再存在直接调用之间的依赖关系，但是usermanagerimple和mysqlda

39、ointerfaceimple类之间还是存在对象创建方面的依赖关系。为了解决这种对象创建方面的依赖关系，经典的gof设计模式中提供了工厂（factory）模式，将对象的创建交给工厂模式中的工厂类来创建。从而也能够达到隔离对象的创建者和对象的使用者的效果。3、用工厂模式来实现类似ioc效果的示例根据gof设计模式中的工厂模式的编程规则，需要定义出下面的各个角色：产品类的接口、产品类的接口的实现、工厂类和调用者客户类。当然，关于工厂模式的更进一步地的说明请见本书的第十一章 “与spring框架相关的设计模式” 中的详细介绍。（1）产品的接口定义下面的【例1-7】中所示的daointerface.j

40、ava代码代表应用系统中的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); publ

41、ic boolean insertoneuserinfo(userinfovo oneuserinfovo); public boolean deleteoneuserinfo(int userid); public boolean updateoneuserinfo(userinfovo newuserinfovo);（2）产品的接口的各个实现类定义下面的【例1-8】中所示的mysqldaointerfaceimple.java和【例1-9】中oracledaointerfaceimple.java分别代表上面的产品的接口的不同的产品实现类，也就是应用系统中所需要创建的各个目标对象的类。限于

42、篇幅，这里对其中的每个方法没有给出具体的功能实现代码。【例1-8】 工厂模式中的产品类的接口的某个实现类代码示例package com.px1987.springwebapp.dao;import com.px1987.springwebapp.model.userinfovo;import java.sql.*;import javax.sql.*;public class mysqldaointerfaceimple implements daointerface public mysqldaointerfaceimple() public boolean deleteoneuserinf

43、o(int userid) public userinfovo getoneuserinfo(string username, string userpassword) public boolean insertoneuserinfo(userinfovo oneuserinfovo) public boolean updateoneuserinfo(userinfovo newuserinfovo) 【例1-9】 工厂模式中的产品类的接口的某个实现类package com.px1987.springwebapp.dao;import com.px1987.springwebapp.model

44、.userinfovo;import java.sql.*;import javax.sql.*;public class oracledaointerfaceimple implements daointerface public oracledaointerfaceimple() public boolean deleteoneuserinfo(int userid) public userinfovo getoneuserinfo(string username, string userpassword) public boolean insertoneuserinfo(userinfo

45、vo oneuserinfovo) public boolean updateoneuserinfo(userinfovo newuserinfovo) （3）工厂类的定义下面的【例1-10】中所示的daobeanfactory.java代表工厂类，利用它来创建出不同类型的产品对象，这些产品对象也就是客户端程序对象所需要的目标对象。对本示例而言，则是在业务层组件中实际所需要的某个目标dao组件对象的实例，由工厂类根据业务层组件的具体需要返回产品接口（也就是本示例中的daointerface接口）的不同的产品实现类的对象实例。【例1-10】工厂模式中的工厂类的代码示例package com.px

46、1987.springwebapp.dao;public class daobeanfactory public static daointerface creatordaobean(int requestdaotype)if (requestdaotype =1)return new oracledaointerfaceimple();else if (requestdaotype =2)return new mysqldaointerfaceimple();在工厂模式中的工厂类通常是根据客户请求时的参数（该参数代表所需要的不同产品对象的实例）来判断应该实例化哪个产品的实现类的对象实例，然后

47、再返回该对象实例。（4）请求者（客户端）类下面的【例1-11】中所示的usermanagerimple.java代表基于工厂模式的请求者，也就是客户端程序类，该类向工厂类发出需要某种形式的产品对象的请求，由工厂类返回某个特定的产品对象实例给客户程序。希望仍然注意其中的黑体部分的代码。【例1-11】 调用类（本示例为业务层组件类）的代码示例package com.px1987.springwebapp.model;import com.px1987.springwebapp.dao.*;public class usermanagerimple implements usermanagerint

48、erfacedaointerface daooperatordbbean=null;public usermanagerimple() public boolean douserlogin(userinfovo oneuserinfo) /可以将下面的类型“1”放到配置文件中，从而更加灵活daooperatordbbean=daobeanfactory.creatordaobean(1); string username=oneuserinfo.getusername();string userpassword=oneuserinfo.getuserpassword(); boolean ok

49、ornot=false;userinfovo returnoneuserinfo=daooperatordbbean.getoneuserinfo(username, userpassword);if(returnoneuserinfo=null)okornot = false;else okornot = true;return okornot;通过工厂模式，最终达到在请求者（客户端）类的方法中实例化某个具体的产品实现类的对象本示例也就是在业务层中获得所需要的某个具体的dao组件类的对象实例，这样对于调用类来说，不直接实例化该实现类而是由工厂类来创建产品对象（工厂模式中工厂类通常根据参数来判断该实例化哪个实现类）。纵然产品的某个实现类发生变化，而调用者的代码仍然可以不作修改，给维护与扩展带来便利。应用系统中的其它组件需要获取产品这个接口的实现类的对象实例，而无需事先获知其具体的实现类的编程实现的细节。从而也能够达到隔离对象的创建者和对象的使用者的效果。4、用