Spring是什么：
Spring是一个轻量级的DI和AOP容器框架。
说它轻量级有一大部分原因是相对与EJB的（虽然本人从没有接触过EJB的应用），重要的是，Spring是非侵入式的，基于spring开发的应用一般不依赖于spring的类。
DI：称作依赖注入(Dependency Injection),和控制反转一个概念，具体的讲，当一个角色需要另外一个角色协助的时候，在传统的程序设计中，通常有调用者来创建被调用者的实例。但是在spring中创建被调用者将不再有调用者完成，因此叫控制反转。创建被调用对象有Spring来完成，在容器实例化对象的时候主动的将被调用者（或者说它的依赖对象）注入给调用对象，因此又叫依赖注入。
AOP：Spring对面向切面编程提供了强有力的支持，通过它让我们将业务逻辑从应用服务（如事务管理）中分离出来，实现了高内聚开发，应用对象只关注业务逻辑，不再负责其它系统问题（如日志、事务等）。Spring支持用户自定义切面。
面向切面编程是面向对象编程的有力补充。面向对象编程将程序分成各个层次的对象，面向切面的程序将运行过程分解成各个切面。AOP是从运行程序的角度去考虑程序的结构，提取业务处理过程的切面，OOP是静态的抽象，AOP是动态的抽象，是对应用执行过程的步骤进行抽象，从而获得步骤之间的逻辑划分。
容器：Spring是个容器，因为它包含并且管理应用对象的生命周期和配置。如对象的创建、销毁、回调等。
框架：Spring作为一个框架，提供了一些基础功能，（如事务管理，持久层集成等），使开发人员更专注于开发应用逻辑。
看完了Spring是什么，再来看看Spring有哪些优点
1.使用Spring的IOC容器，将对象之间的依赖关系交给Spring，降低组件之间的耦合性，让我们更专注于应用逻辑
2.可以提供众多服务，事务管理，WS等。
3.AOP的很好支持，方便面向切面编程。
4.对主流的框架提供了很好的集成支持，如hibernate,Struts2,JPA等
5.Spring DI机制降低了业务对象替换的复杂性。
6.Spring属于低侵入，代码污染极低。
7.Spring的高度可开放性，并不强制依赖于Spring，开发者可以自由选择Spring部分或全部
官网：http://spring.io/ 中文：https://springcloud.cc/
Spring的优势不言而喻：
1. 提供了一种管理对象的方法，可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。
2. 采用了分层结构，可以增量引入到项目中。
3. 有利于面向接口编程习惯的养成。
4. 目的之一是为了写出易于测试的代码。
5. 非侵入性，应用程序对Spring API的依赖可以减至最小限度。
6. 一致的数据访问介面。
6. 一个轻量级的架构解决方案
缺点也显而易见
1. 中断了应用程序的逻辑，使代码变得不完整，不直观。此时单从Source无法完全把握应用的所有行为。
2. 将原本应该代码化的逻辑配置化，增加了出错的机会以及额外的负担。
3. 时光倒退，失去了IDE的支持。在目前IDE功能日益强大的时代，以往代码重构等让人头痛的举动越来越容易。而且IDE还提供了诸多强大的辅助功能，使得 编程的门槛降低很多。通常来说，维护代码要比维护配置文件，或者配置文件+代码的混合体要容易的多。
4. 调试阶段不直观，后期的bug对应阶段，不容易判断问题所在。
经典架构S（Struts）SH的优缺点
Struts、Spring、Hibernate能流行这么多年经久不衰，自然有它的道理。J2EE最先出现的时候，我们一般是采用 JSP+Servlet+JavaBean+EJB的架构，尤其是1998年～2000年这段时间，互联网的泡沫从兴起到破裂，其波澜壮阔程度，丝毫不亚 于2008年开始的这次经济危机，在那个年代，是否掌握EJB开发技术将直接决定你的薪水能否翻一倍或者几倍。不过，Spring的作者Rod Johnson在2002年根据多年经验撰写了《Expert o-ne-on-One J2EE Design and Development》，其后又发表了著名的《Expert o-ne-on-one J2EE Development without EJB》一书，则彻底地改变了传统的J2EE一统天下的开发架构，基于Struts+Hibernate+Spring的J2EE架构也逐渐得到人们的认 可，甚至在大型的项目架构中也逐渐开始应用。下面我们分别说说Spring、Struts和Hibernate的优缺点。
Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，使得每个层之间和类与类之间的关系，由原来的强绑定与强 耦合转变为不绑定和松耦合，直接面向接口编程，把设计与实现相分离的原则发挥到极致，对于单元测试也产生了很深远的影响。在Spring出现之前，如果某 个模块没有完成，做单独模块的单元测试还是很困难的。Spring同时也是 J2EE 应用程序开发的集成框架，因为J2EE是讲究分层理念的，Spring使得J2EE每个层之间的模块职能更加清晰。
不过，对于大型项目的开发，Spring使得原来难以维护的类与类之间的强耦合关系，转变为更加难以维护的XML文件配置，这个工作量也是非常巨大 的，而且更容易出错。而且，随着每个应用 模块的升级，这些模块之间的版本，也不会是同步更新的，对于同一个公共组件，有的模块用的可能是1.0版本，而另 外一个功能模块用的可能是2.0版本，可怕的是1.0版本和2.0版本之间，可能还不兼容，Spring对于这些需求，就无能为力了。所以，有人说 Spring不适合大型项目开发，也是有一定道理的。最近Spring也加入了OSGI标准的实现，也是为了解决不同版本之间同时存在的这些问题。不过， 随着Spring加入的功能越来越多，Spring也就失去了轻量开源框架的特点，变得越来越笨重。
虽然Spring现在也支持了所谓的免配置，可以通过@Autowired标签自行绑定，还可以通过 设置自动绑定加载所有的Hibernate对象，但是如果这些上百个或者数十个中的任何一个Entity对象加载失败，则整个Spring服务就启动不起 来了，这与难于部署的EJB有啥区别呢？而且，令人可笑的是，由于使用了@Autowired标签，相当一部分开发人员不再面向接口编程了，对于 Class A的实例，美其名曰由Spring自行绑定，接口也好，实际实现类也好，就在Spring配置一下就可以了。而Spring最核心的就是面向接口编程和 IOC，没有了面向接口编程，用一个 A a=new A() 来实例化一个Class，有什么不可以呢？少写了一行代码，引入了一个重量级的Spring，究竟为啥使用Spring呢？
对于Hibernate的流行，则是由于开发人员和客户，对于Entity EJB（实体EJB）臃肿的身材及部署的困难，是在极度失望情绪下造成的。既然是轻量级解决方案，那么分布式就不是可选项，没有分布式，那么EJB就无用 武之地了。话又说回来了，Rod Johnson前些年就因为强调绝大部分企业应用是不需要分布式的，从而推出了自己轻量级的Spring解决方案。但是最近一年，随着云计算架构的兴起， 架构是否支持分布式，又是必选项了。技术架构的选型，就跟法国巴黎流行时装一样，今年流行短袖，明年流行下摆，真是典型的十年河东，十年河西。所以，像 SOA、云计算、SaaS、物联网这些大名词，不仅会给客户带来很大的困惑，同样也会给程序员、系统分析师、系统架构师、技术总监带来困惑。从肯定到否 定，再到自我否定，真是符合大自然螺旋式上升的发展规律。
而对于Struts，它一经推出，几乎打败了当时的所有竞争对手。Struts的伟大之处，在于它对网页数据的动态绑定。虽然数据绑定不是一个新名 词，微软在1991年推出Visual Basic1.0的时候，就创造性地发明了让VB程序员又爱又恨的数据绑定，但是对于Web 编程，Struts也还是把数据绑定首次应用到了Web编程上。它能够让人们用Set和Get的形式取得网页数据，而不是单一的黑盒式的 request.getParameter()，从而使得网页数据取值进入面向对象（OO）化时代。
Struts、Hibernate以及Spring本身都是制作精良的框架，但是对于自己产品和项目的应用，一经整合在一起，却不一定很适用。比如 说，对于数据库相关的MIS（管理信息系统）系统中，增加、修改、删除、查询功能是最基本、最常见、必不可少的。对于这些最基本的功能，不同的架构师，则 会做出不同的选择。有的架构师，选择了自动生成的理念，做一个代码自动生成器，设计好数据库表结构，单击一个脚本，或者用Eclipse插件的形式，做个 图形化生成界面，自动生成SSH框架，完成数据库的增加、修改、删除、查询操作。这么做的好处是数据库修改了，代码自动生成就可以了，使得程序员不用再维 护这些无聊的代码。不过缺陷也是致命的，一是随着Struts、Hibernate、Spring的升级，这个工具也不得不跟着升级，而做这个工具的程序 员，可能早就离开公司了，后续版本无法维护；二是如果有的业务逻辑跟这些生成的代码有交叉，数据库变更后，代码也无法再次生成了。三是公司的系统架构，则 被严重限制在SSH架构基础上，再也无法改变。有人会问：即使限制在这三种架构上，有何不好吗？假设有客户问，你的框架支持云计算吗？你总不能说”由于 Struts、Hibernate、Spring 不支持云计算架构，所以我也不支持”以此取得客户谅解吧。因此，依赖于第三方架构的产品体系架构，随着时间的推移，受到的限制会越来越大。
