谈谈对springhibernatestruts2的理解.docx

谈谈对springhibernatestruts2的理解.docx

《谈谈对springhibernatestruts2的理解.docx》由会员分享，可在线阅读，更多相关《谈谈对springhibernatestruts2的理解.docx（17页珍藏版）》请在冰豆网上搜索。

谈谈对springhibernatestruts2的理解

面试的时候的一个问题,说得越详细越容易理解越好.

我对spring的理解

主要有反转控制和面向切面（AOP）,

面试题:

说说你对spring的理解

[此问题的推荐答案]

spring:

1）是一种开源框架,实际上就是一种容器,是实现了IOC模式的容器，也可以说是一个Bean的工厂，对Bean进行管理。

2）IoC（控制反转）,将类的创建和依赖关系写在配置文件里，由配置文件注入，实现了松耦合

3）AOP将安全，事务，log等公共的服务对于程序逻辑相对独立的功能抽取出来，利用spring的配置文件将这些功能插进去，让程序员更专注于业务逻辑的实现，实现了按照方面编程，提高了可维护性和复用性

4）ApplicationContext：

spring上下文信息，

5）SpringDAO

6）springORM:

可以集成多个ORM框架，像Hibernate，Ibatis，JDO，

7）springWeb模块,与struts的集成。

8）springMVC

spring容器的接口分级设计。

IoC和AOP是spring最重要的两个特性，面试官差不多就看这个吧，至于springmvc之类的估计面试官不一定感兴趣

介绍Spring的核心

Spring的核心是个轻量级容器（container），实现了IoC（InversionofControl）模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代，Spring希望提供one-stopshop的框架整合方案。

Spring不会特別去提出一些子框架来与现有的OpenSource框架竞争，除非它觉得所提出的框架夠新夠好，例如Spring有自己的MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但它不强迫您使用它提供的方案，您可以选用您所希望的框架来取代其子框架，例如您仍可以在Spring中整合您的Struts框架。

Spring的核心概念是IoC，IoC的抽象概念是「依赖关系的转移」，像是「高层模组不应该依赖低层模组，而是模组都必须依赖于抽象」是IoC的一种表现，「实现必须依赖抽象，而不是抽象依赖实现」也是IoC的一种表现，「应用程序不应依赖于容器，而是容器服务于应用程序」也是IoC的一种表现。

spring框架由七个模块组成;

其核心容器:

提供基本功能,主要核心BeanFactory工厂模式的实现,使用控制反转（依赖注入）实现.让Bean与Bean之间以配置文件组织在一起,而不是以硬编码的方式耦合在一起.创建实例由spring容器来完成.创建对象的控制权由调用者交给了容器来管理,这就是控制反转名字的由来.

 所谓依赖注入,是指在程序运行过程中,当需要被调用时,由容器自己提供被调用者的实例,调用者与被调用者都处于spring管理下,二者之间的以来关系有spring提供.

 spring框架的核心思想是建立一个java对象的工厂,用户只要给工厂一个指令,工厂就能将用户需要的对象根据配置文件组装好还给用户.

 业务层service控制层Action 持久层DAO 各层之间调用完全面向接口,无需关心其具体实现的类,当重构代码时,改写量将大大减少.

白话解说Spring容器设计理念

李俊杰

概述

Spring是为了解决企业应用程序开发复杂性而创建的开源框架，书店上关于Spring的书籍汗牛充栋，网上相关的文章连篇累牍，其中有很多写的很不错的，有入门例子的，有问题解决方案的，有环境设置的，有源代码分析的，有spring与其他开源系统集成的，不一而足。

本文通过生活白话，不拘泥于Spring源代码和专业术语的束缚，不拘泥于具体的实现细节，类比介绍Spring容器的宏观的设计理念。

让Spring容器走下神坛

Spring容器提供Spring框架的基本功能，是工厂模式的实现。

换句话说，Spring就是Bean的工厂，管理Bean的生命周期。

那如何来设计呢？

Spring源代码虽不说是浩如烟海，也让人头晕目眩，如下图所示，我们让Spring容器走下神坛，既然是面向接口编程，用接口来描述框架，不必拘泥于具体实现可能更清晰些。

任何的设计都是这样，有原料，有入口，有加工，也有出口。

既然Spring是Bean的容器，是Bean的工厂，那么生产Bean流程是：

1）原料：

bean的配置文件

2）进料：

通过ResourceLoader把xml文本文件读入

3）初加工：

通过BeanDefinitionReader把原料加工成半成品BeanDefinition

4）精加工：

Bean的生产车间BeanFactory把半成品BeanDefinition加工成Bean

5）入库：

成品库SingletonRegistry保存成品Bean，及Bean的标签（beanId），呵呵！

你也知道这就是Map的工作了

IOC是Sprng核心？

关键？

Spring容器使用控制反转（IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开，控制反转（IOC）模式是基于java反射的基本原理。

通常的软件设计，肯定把IOC作为容器的核心，其他外围的功能如bean的Scope都是基于IOC展开，而Spring设计却只把它放如工具类BeanUtil，这正是Spring的高明之处，虽然IOC是Spring的创建bean的基础，但创建一个bean需要判断是否静态工厂创建，是否有含参数的构造方法，而这些参数也可能是其他对象的实例，创建bean的初始化方法等等，这些不仅仅是bean的IOC所能涵盖的，并且在创建一个bean的过程中可能需要多次迭代调用IOC程序。

综上所述，IOC虽然是Spring的创建Bean的基本原理，但仅是及其重要的一部分，并不是Spring容器的核心，是Spring创建bean的比不可少的工具。

IOC是Spring容器的关键，而不是核心。

Interface分级设计

接口的分级设计，是针对不同的客户给予不同级别的产品。

不同等级的接口关注点也各有不同，就像产品也分为多个级别，如高级产品、中级产品、初级产品分别对应于不同的客户群，或者如同银行的客户渠道有银行卡，柜台，网银，手机终端，ATM机等等。

同样接口也分为内部接口和外部接口，就如同有些接口可能永远不被外部用户所知，仅仅是内部使用，就像工厂内部多个车间之间的内部产品。

org.springframework.beans.factory.BeanFactory是Spring的顶级Interface，其中只有getBean系列，containsBean，isPrototype，isSingleton，getType等成品Bean的基本方法。

org.springframework.beans.factory.ListableBeanFactory是Factory的管理方法如containsBeanDefinition，getBeanDefinitionCount，getBeanDefinitionNames，getBeanNamesForType系列，getBeansOfType系列，ListableBeanFactory是针对BeanDefinition半成品的。

而ApplicationContext接口除了集成ListableBeanFactory接口外，还继承了ResourcePatternResolver，HierarchicalBeanFactory，ApplicationEventPublisher，MessageSource的功能，如在资源处理（国际化处理），事件传递，及各应用层之间的context实现。

同样是对外的接口，Spring更建议采用ApplicationContext的原因也就在这儿，ApplicationContext更像是针对VIP客户的产品。

Interface扩展设计

Spring设计是开放性的设计思路，是值得我们做架构设计人员学习的，如下图所示：

Spring设计是开放性的设计思路，是值得我们做架构设计人员学习的，如下图所示：

com.springframework.beans.factory

（淡黄色背景）

|BeanFactory

|ListableBeanFactory

|ConfigrableListableBeanFactory

|DefaultListableBeanFactory

com.springframework.context

（棕红色背景）

ApplicationContext

ConfigrableApplicationContext

org.springframework.context

（黄色背景）

.support

AbstractApplicationContext

AbstractRefreshableApplicationContext

AbstractXmlApplicationContext

ClassPathXmlApplicationContext

org.springframework.web.context

（绿色背景）

WebApplicationContext

ConfigrableWebApplicationContext

org.springframework.web.context

（浅蓝色背景）

.support

AbstractRefreshableWebApplicationContext

XmlWebApplicationContext

Spring设计是开放性的设计思路，是值得我们做架构设计人员学习的，如下图所示：

com.springframework.beans.factory

（淡黄色背景）

|BeanFactory

|ListableBeanFactory

|ConfigrableListableBeanFactory

|DefaultListableBeanFactory

com.springframework.context

（棕红色背景）

ApplicationContext

ConfigrableApplicationContext

org.springframework.context

（黄色背景）

.support

AbstractApplicationContext

AbstractRefreshableApplicationContext

AbstractXmlApplicationContext

ClassPathXmlApplicationContext

org.springframework.web.context

（绿色背景）

WebApplicationContext

ConfigrableWebApplicationContext

org.springframework.web.context

（浅蓝色背景）

.support

AbstractRefreshableWebApplicationContext

XmlWebApplicationContext

Spring设计是开放性的设计思路，是值得我们做架构设计人员学习的，如下图所示：

com.springframework.beans.factory

（淡黄色背景）

|BeanFactory

|ListableBeanFactory

|ConfigrableListableBeanFactory

|DefaultListableBeanFactory

com.springframework.context

（棕红色背景）

ApplicationContext

ConfigrableApplicationContext

org.springframework.context

（黄色背景）

.support

AbstractApplicationContext

AbstractRefreshableApplicationContext

AbstractXmlApplicationContext

ClassPathXmlApplicationContext

org.springframework.web.context

（绿色背景）

WebApplicationContext

ConfigrableWebApplicationContext

org.springframework.web.context

（浅蓝色背景）

.support

AbstractRefreshableWebApplicationContext

XmlWebApplicationContext

总结如下：

1）不同的包下面放不同的东西，好像是废话啊！

上层包放接口，下层包放实现的抽象类及实体类。

如contex.support包下面放实现context包下面的接口的抽象类及实现类。

2）为了适应WEB级别的ApplicationContext，创建了WebApplicationContext的接口，该接口继承了ApplicationContext，又添加了WEB层的个性化方法如getServletContext及属性。

现在终于明白了在接口间的“extends”的含义，绝对是对上层接口的“扩展“，扩展的目的是适应更具体化的环境。

就如同因为国家大，情况复杂，中央的政策相对都是比较抽象的，而地方政策必须结合地方的特色，既要满足中央政策的要求，即实现中央政策的接口，又要根据本地特殊情况，扩展个性化的政策，即地方政策接口，从而更具有可操作性。

3）在org.springframework.web.context.support.AbstractRefreshableWebAppplicationContext类是既实现了ConfigrableWebApplicationContext接口，即实现WEB的个性化特色，又继承了org.springframework.context.support.AbstractRefreshableApplicationContext类。

借助了已有的类，实现了架构上的复用，这就像制定政策既要满足地方上的特色，又可以参照其他地区现成的政策经验。

呵呵！

在实际工作中，也会常常有这样的设计。

努力，在于我热爱我的事业，与中国的软件一起走向成熟，走向世界。

联系作者：

lijj_72@

本文来自CSDN博客，转载请标明出处：

相对于Ioc，Aop这些概念,我觉得spring带来更重要的是容器观念。

从一定意义上说，spring是出于ejb又高于ejb的设计（ejb2），有些概念是互通的，特别是容器的思想。

ejb就是运行在容器里的，只是ejb自身的代价和为了使用ejb而花费的代价都太高了（纯粹的技术观点，前者是直觉，我没有看过一行ejb实现代码；后者是切身之痛，要在一个项目中有效编写ejb，有三分之二的时间是花在上课上），spring的过人之处就在于将容器和pojo联系了起来。

有了容器，所有底层的构建全都从代码中分离了，这是所谓的松耦合和ioc的基础。

但容器的功能不单单如此，因为创建对象的过程被容器所管理，所以我就可以在创建过程中动些手脚，于是Aop就自然的被实现出来了。

相比较于其他的javaaop方案，spring上的aop实现显得更平易近人。

最后，将容器引入，从此代码获得了真正的灵活性，所谓的迭代式开发等方法能够真正的得到落实。

只作现在想到到的，从此不用过渡设计，如果有新的要求，稍作修改，再让容器帮我搞定新增部分集成就是了。

联想开来，容器作用就类似于计算机硬件主板，每个新增类就像是往板卡上插新卡一般，但是同硬件相比现在的容器还没有一个比较标准的总线概念，特别是同一个虚拟机内非容器管理bean和容器之间的通讯；以及两个容器之间的通讯现在还很薄弱。

现在每次做项目往往为了集成非spring创建的bean而苦恼（前几天用了一下AutowireCapableBeanFactory稍微降低了点工作量）。

我希望的软件通讯协议最好是可伸缩的，首先对于一般的java应用是很简单的配置，在同一个虚拟机里通讯应该不会有太大的开销；但是当我需要同一个异构的端点通讯时，可以提供企业级的标准通讯协议，比如webservice。

引入了容器之后，越发觉得自己可控制的东西越来越少了，不过这何尝不是件好事呢？

这个应该是心理学问题，就不讨论了：

）

struts最早是作为ApacheJakarta项目的组成部分问世运作。

项目的创立者希望通过对该项目的研究，改进和提高JavaServerPages、Servlet、标签库以及面向对象的技术水准。

Struts这个名字来源于在建筑和旧式飞机中使用的支持金属架。

它的目的是为了减少在运用MVC设计模型来开发Web应用的时间。

你仍然需要学习和应用该架构，不过它将可以完成其中一些繁重的工作。

Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点，使开发者能更深入的了解其内部实现机制。

Spring是一个开源框架，它由RodJohnson创建。

它是为了解决企业应用开发的复杂性而创建的。

Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。

然而，Spring的用途不仅限于服务器端的开发。

从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。

•目的：

解决企业应用开发的复杂性•功能：

使用基本的JavaBean代替EJB，并提供了更多的企业应用功能•范围：

任何Java应用简单来说，Spring是一个轻量级的控制反转（IoC）和面向切面（AOP）的容器框架。

在SSH框架中spring充当了管理容器的角色。

我们都知道Hibernate用来做持久层，因

为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语

句。

Struts是用来做应用层的，他它负责调用业务逻辑serivce层。

所以SSH框架的流程大致

是：

Jsp页面----Struts------Service（业务逻辑处理类）---Hibernate（左到右）struts

负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的

依赖和强，属于耦合。

这时，使用spring框架就起到了控制Action对象（Strus中的）和

Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正

是用在此处。

Spring的Ioc（控制反转和依赖注入）

控制反转：

就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直

接操控。

依赖注入：

组件之间的依赖关系由容器在运行期决定，由容器动态的将某种依赖关系注

入到组件之中。

从上面我们不难看出：

从头到尾Action仅仅是充当了Service的控制工具，这些具体的

业务方法是怎样实现的，他根本就不会管，也不会问，他只要知道这些业务实现类所提供的

方法接口就可以了。

而在以往单独使用Struts框架的时候，所有的业务方法类的生命周期，

甚至是一些业务流程都是由Action来控制的。

层与层之间耦合性太紧密了，既降低了数据访

问的效率又使业务逻辑看起来很复杂，代码量也很多。

，Spring容器控制所有Action对象和业务逻辑类的生命周期，由与上层不再控制下层的生命周期，层与层之间实现了完全脱耦，

使程序运行起来效率更高，维护起来也方便。

使用Spring的第二个好处（AOP应用）：

事务的处理：

在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch来完成，而在

Spring中。

Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能，

包括异常时事务回滚，操作成功时数据提交等复杂业务功能。

这都是由Spring容器来管理，

大大减少了程序员的代码量，也对事务有了很好的管理控制。

Hibernate中也有对事务的管

理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。

而Spring对SessionFactory配置也进行了整合，不需要在通过hibernate.cfg.xml来对

SessionaFactory进行设定。

这样的话就可以很好的利用Sping对事务管理强大功能。

避免

了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的

Try/Catch操作。

这些也就是Spring中的AOP（面向切面编程）机制很好的应用。

一方面使开发业务逻辑更清晰、专业分工更加容易进行。

另一方面就是应用SpirngAOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。

Struts对Model，View和Controller都提供了对应的组件。

在右图中，ActionServlet，这个类是Struts的核心控制器，负责拦截来自用户的请求。

Action，这个类通常由用户提供，该控制器负责接收来自ActionServlet的请求，并根据该请求调用模型的业务逻辑方法处理请求，并将处理结果返回给JSP页面显示。

Model部分

由ActionForm和JavaBean组成，其中ActionForm用于封装用户的请求参数，封装成ActionForm对象，该对象被ActionServlet转发给Action，Action根据ActionFrom里面的请求参数处理用户的请求。

JavaBean则封装了底层的业务逻辑，包括数据库访问等。

View部分

该部分采用JSP（或HTML、PHP……）实现。

Struts提供了丰富的标签库，通过标签库可以减少脚本的使用，自定义的标签库可以实现与Model的有效交互，并增加了现实功能。

对应上图的JSP部分。

Controller组件

Controller组件有两个部分组成——系统核心控制器，业务逻辑控制器。

系统核心控制器，对应上图的ActionServlet。

该控制器由Struts框架提供，继承HttpServlet类，因此可以配置成标注的Servlet。

该控制器负责拦截所有的HTTP请求，然后根据用户请求决定是否要转给业务逻辑控制器。

业务逻辑控制器，负责处理用户请求，本身不具备处理能力，而是调用Model来完成处理。

对应Action部分。

Spring

Spring是一个开源框架，它由RodJohnson创建。

它是为了解决企业应用开发的复杂性而创建的。

Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。

然而，Spring的用途不仅限于服务器端的开发。

从简单性、可测