ssh，

ssh，

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

我对spring的理解

主要有反转控制和面向切面（AOP）,
面试题:说说你对spring的理解
[此问题的推荐答案]
spring: 1)是一种开源框架,实际上就是一种容器,是实现了IOC模式的容器，也可以说是一个Bean的工厂，对Bean进行管理。
2)IoC（控制反转）,将类的创建和依赖关系写在配置文件里，由配置文件注入，实现了松耦合
3)AOP 将安全，事务，log等公共的服务对于程序逻辑相对独立的功能抽取出来，利用spring的配置文件将这些功能插进去，让程序员更专注于业务逻辑的实现，实现了按照方面编程，提高了可维护性和复用性
4) ApplicationContext：spring上下文信息，
5) Spring DAO
6)spring ORM:可 以集成多个ORM框架，像Hibernate，Ibatis，JDO，
7）spring Web模块,与struts的集成。
8）spring MVC
spring容器的接口分级设计。
IoC和AOP是spring最重要的两个特性，面试官差不多就看这个吧，至于spring mvc之类的估计面试官不一定感兴趣



介绍Spring的核心
Spring的核心是个轻量级容器（container），实现了IoC（Inversion of Control）模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代，Spring希望提供one-stop shop的框架整合方案 。
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@hotmail.com


本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lijj_72/archive/2009/01/10/3747719.aspx


相对于Ioc，Aop这些概念,我觉得spring带来更重要的是容器观念。
从一定意义上说，spring是出于ejb又高于ejb的设计(ejb 2)，有些概念是互通的，特别是容器的思想。ejb就是运行在容器里的，只是ejb自身的代价和为了使用ejb而花费的代价都太高了（纯粹的技术观点，前者是直觉，我没有看过一行ejb实现代码；后者是切身之痛，要在一个项目中有效编写ejb，有三分之二的时间是花在上课上），spring的过人之处就在于将容器和pojo联系了起来。

有了容器，所有底层的构建全都从代码中分离了，这是所谓的松耦合和ioc的基础。但容器的功能不单单如此，因为创建对象的过程被容器所管理，所以我就可以在创建过程中动些手脚，于是Aop就自然的被实现出来了。相比较于其他的java aop方案，spring上的aop实现显得更平易近人。最后，将容器引入，从此代码获得了真正的灵活性，所谓的迭代式开发等方法能够真正的得到落实。只作现在想到到的，从此不用过渡设计，如果有新的要求，稍作修改，再让容器帮我搞定新增部分集成就是了。

联想开来，容器作用就类似于计算机硬件主板，每个新增类就像是往板卡上插新卡一般，但是同硬件相比现在的容器还没有一个比较标准的总线概念，特别是同一个虚拟机内非容器管理bean和容器之间的通讯；以及两个容器之间的通讯现在还很薄弱。现在每次做项目往往为了集成非spring创建的bean而苦恼（前几天用了一下AutowireCapableBeanFactory稍微降低了点工作量）。我希望的软件通讯协议最好是可伸缩的，首先对于一般的java应用是很简单的配置，在同一个虚拟机里通讯应该不会有太大的开销；但是当我需要同一个异构的端点通讯时，可以提供企业级的标准通讯协议，比如web service。

引入了容器之后，越发觉得自己可控制的东西越来越少了，不过这何尝不是件好事呢？这个应该是心理学问题，就不讨论了：）


struts最早是作为Apache Jakarta项目的组成部分问世运作。项目的创立者希望通过对该项目的研究，改进和提高Java Server Pages、Servlet、标签库以及面向对象的技术水准。Struts这个名字来源于在建筑和旧式飞机中使用的支持金属架。它的目的是为了减少在运用MVC设计模型来开发Web应用的时间。你仍然需要学习和应用该架构，不过它将可以完成其中一些繁重的工作。Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点，使开发者能更深入的了解其内部实现机制。 Spring是一个开源框架，它由Rod Johnson创建。它是为了解决企业应用开发的复杂性而创建的。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（面向切面编程）机制很好的应用。一方面使开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng AOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。


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是一个开源框架，它由Rod Johnson创建。它是为了解决企业应用开发的复杂性而创建的。Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。
目的：解决企业应用开发的复杂性
功能：使用基本的JavaBean代替EJB，并提供了更多的企业应用功能
范围：任何Java应用
简单来说，Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架。
轻量——从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于Spring的特定类。
控制反转——Spring通过一种称作控制反转（IoC）的技术促进了松耦合。当应用了 IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。
面向切面——Spring提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（transaction）管理）进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。
容器——Spring包含并管理应用对象的配置和生命周期，在这个意义上它是一种容器，你可以配置你的每个bean如何被创建——基于一个可配置原型（prototype），你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例 ——以及它们是如何相互关联的。然而，Spring不应该被混同于传统的重量级的EJB容器，它们经常是庞大与笨重的，难以使用。
框架——Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中，应用对象被声明式地组合，典型地是在一个XML文件里。Spring也提供了很多基础功能（事务管理、持久化框架集成等等），将应用逻辑的开发留给了你。
所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种模块提供了基础支持。
Hibernate
Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。
Hibernate的核心接口一共有5个，分别为:Session、 SessionFactory、Transaction、Query和Configuration。这5个核心接口在任何开发中都会用到。通过这些接口，不仅可以对持久化对象进行存取，还能够进行事务控制。下面对这五个核心接口分别加以介绍。
•Session接口:Session接口负责执行被持久化对象的CRUD操作(CRUD的任务是完成与数据库的交流，包含了很多常见的SQL语句。)。但需要注意的是Session对象是非线程安全的。同时，Hibernate的session 不同于JSP应用中的HttpSession。这里当使用session这个术语时，其实指的是Hibernate中的session，而以后会将 HttpSesion对象称为用户session。
•SessionFactory接口:SessionFactory接口负责初始化 Hibernate。它充当数据存储源的代理，并负责创建Session对象。这里用到了工厂模式。需要注意的是SessionFactory并不是轻量级的，因为一般情况下，一个项目通常只需要一个SessionFactory就够，当需要操作多个数据库时，可以为每个数据库指定一个 SessionFactory。
•Configuration接口:Configuration接口负责配置并启动 Hibernate，创建SessionFactory对象。在Hibernate的启动的过程中，Configuration类的实例首先定位映射文档位置、读取配置，然后创建SessionFactory对象。
•Transaction接口:Transaction接口负责事务相关的操作。它是可选的，开发人员也可以设计编写自己的底层事务处理代码。
•Query和Criteria接口:


对Spring的理解 收藏
原帖地址:http://www.iteye.com/topic/10817?page=1


一、Spring的IoC(Inversion of Control)

这是Spring中得有特点的一部份。IoC又被翻译成“控制反转”，也不知道是谁翻译得这么别扭，感觉很深奥的词。其实，原理很简单，用一句通俗的话来说：就是用XML来定义生成的对象(设计成ioc的程序可以很容易用ioc容器装配起来。而ioc容器通过读取配置文件进行装配。spring常用的是用xml格式的配置文件)。IoC其实是一种设计模式，Spring只是实现了这种设计模式。

这种设计模式是怎么来的呢？是实践中逐渐形成的。

第一阶段：用普通的无模式来写Java程序。一般初学者都要经过这个阶段。
第二阶段：频繁的开始使用接口，这时，接口一般都会伴随着使用工厂模式。
第三阶段：使用IoC模式。

工厂模式还不够好：

（1）因为的类的生成代码写死在程序里，如果你要换一个子类，就要修改工厂方法。

（2）一个接口常常意味着一个生成工厂，会多出很多工厂类。

可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词，通俗的说反射就是根据给出的类名（字符串）来生成对象。这种编程方式可以让对象在生成时才决定要生成哪一种对象。我在最近的一个项目也用到了反射，当时是给出一个.properties文本文件，里面写了一些全类名（包名＋类名），然后，要根据这些全类名在程序中生成它们的对象。反射的应用是很广泛的，象Hibernate、String中都是用“反射”做为最基本的技术手段。

在过去，反射编程方式相对于正常的对象生成方式要慢10几倍，这也许也是当时为什么反射技术没有普通应用开来的原因。但经SUN改良优化后，反射方式生成对象和通常对象生成方式，速度已经相差不大了（但依然有一倍以上的差距）。

所以要理解IoC，你必须先了解工厂模式和反射编程，否则对它产生的前因后果和实现原理都是无法理解透彻的。只要你理解了这一点，你自己也完全可以自己在程序中实现一个IoC框架，只不是这还要涉及到XML解析等其他知识，稍微麻烦一些。

IoC最大的好处是什么？因为把对象生成放在了XML里定义，所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是现实于某种接口的），只要修改XML就可以了，这样我们甚至可以实现对象的热插拨（有点象USB接口和SCIS硬盘了）。

IoC最大的缺点是什么？

（1）生成一个对象的步骤变复杂了（其实上操作上还是挺简单的），对于不习惯这种方式的人，会觉得有些别扭和不直观。

（2）对象生成因为是使用反射编程，在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。

（3）缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么你还需要去XML文件里手工去改了，这似乎是所有XML方式的缺憾所在。

总的来说IoC无论原理和实现都还算是很简单的。一些人曾认为IoC没什么实际作用，这种说法是可以理解的，因为如果你在编程中很少使用接口，或很少使用工厂模式，那么你根本就没有使用IoC的强烈需要，也不会体会到IoC可贵之处。有些人也说要消除工厂模式、单例模式，但是都语焉不详、人云亦云。但如果你看到IoC模式和用上Spring，那么工厂模式和单例模式的确基本上可以不用了。但工厂模式和单例模式消失了吗？没有！Spring的IoC实现本身就是一个大工厂，其中也包含了单例对象生成方式，只要用一个设置就可以让对象生成由普通方式变单一实例方式，非常之简单。

总结：
（1）IoC原理很简单，作用的针对性也很强，不要把它看得很玄乎。
（2）要理解IoC，首先要了解“工厂、接口、反射”这些概念。

二、Spring的MVC

如果你已经熟悉Struts，那么不必把MVC做为重点学习内容。基本上我认为Spring MVC是一个鸡肋，它的技术上很先进，但易用性上没有Struts好。而且Struts有这么多年的基础了，Spring很难取代Struts的地位。这就是先入为主的优秀，一个项目经理选用一种框架，不能单纯的从它的技术上考虑，还有开发效率，人员配置等都是考虑因素。但做为研究性的学习，Spring的MVC部份还是蛮有价值的。

三、数据库层的模板

Spring主要是提供了一些数据库模板（模板也是一种Java设计模式），让数据部分的代码更简洁，那些try...catch都可以不见了。这个的确是个好东东。



四、AOP

AOP又称面向方面编程，它的实现原理还是用了反射：通过对某一个种类的方法名做监控来实现统一处理。比如：监控以“insert”字符串开头的方法名，在这种方法执行的前后进行某种处理（数据库事务等）。但这里我有一个疑问？不一定所有以insert开头的方法都是数据库操作，哪么当某个insert开头的方法不是数据库操作，你又对它进行了数据事务的操作，这样的错误如何防止？？？我对这方面了解不深，还是只知道一个大概。

曾看过一个程序员发出这样的感慨："框架一个接一个，学也学不完，而且有必要吗？这样一层层的加上框架，还不如直接写JSP来得直接，效率还高。"

我想这种困惑很多人都有吧？但如果你经过的项目渐多，就会发现，维护项目要比开发项目更艰难，代价更大。那种用JSP直接来写，层次又不清楚的开发，往往最后得到一个不可再修改的软件，一团乱麻，移一发而动全身。但软件不象电视机，做好了就不会改动了，软件是一个变化的事物，用户的需求随时会改变，这时你会体会到分层和使用框架的好处了，它们为你做了软件中很多和业务无关的工作，你可以只关注业务，并减少代码量。唯一缺点就是有一个学习的代价，框架配置上也较麻烦。

学习框架，我认为应该：
第一步，了解这个框架中的一些关键概念，它的具体含义是什么。
第二步，了解这个框架的精华在哪里，它能对开发起到什么样的作用，最好能对它的原理有一定的了解。
第三步，用这个框架来写几个例子，实际体会一下