也谈Spring，为何用它？

一个老生常谈的话题，最近出去面试，十之八九还会问这个，今天在博客园里有人说Spring的问题，忍不住点进去看了看，感觉没说出个所以然，所以写篇小文谈谈我的看法。

 

Spring的由来在其作者Rod Johnson的两本名著（《Expert One-on-One J2EE Development without EJB》和《Expert One-on-One J2EE Design and Development》）中讲得清清楚楚，这里所说的大部分是在拾人牙慧，没办法，多年前的东西现在还是需要重复。

从历史上看，Spring是在对当时横行Java世界的企业级应用的标准解决方案EJB的反叛中产生的。如果你对EJB是什么不清楚的话，没关系，反正在我看来这玩意儿就是个怪物，绝大部分企业应用场景下根本不需要它。这么说吧，从国外到国内，用过EJB的人几乎都会有一大堆血泪般的控诉（这里指的是EJB1和EJB2，我承认EJB3改进了很多），这是一个规范复杂丑陋难以理解、侵入式、难测试、生产率低的被厂商炒作出来的东西，看看EJB1、EJB2的规范文档后会发现其已完全背离简化企业应用开发的初衷（对于EJB的声讨，翻翻Javaeye在03年左右的帖子可以看到很多，这里不再赘述）。

EJB缺点很多，但绝非一无是处，要不那么多项目强忍着用它完全是找虐。它还是提供了很多有价值的东西，如声明性事务、O/R Mapping、各种池的管理、集群、远程调用等，这些是在企业应用开发中经常会用到的，理论上说EJB提供的这些可以提高生产率，让开发者分离关注点，将更多精力放在业务梳理和实现上，而不必太过操心这类所有JavaEE项目中通常都需要考虑的东西。

所有这些通用的东西就叫企业级服务，当时能够提供这些企业级服务的基础设施就是EJB容器。在市场上只有EJB时是这样的局面：你要么全部接受EJB的这一套复杂繁琐的规范，要么只能从头一步步自己实现所有企业级服务。

面对这种两难困境，Spring出现了，可以说它解放了生产力，给开发人员提供了一个更光明的未来。Spring是一个轻量级的无侵入的容器。所谓”容器“说白了就是代码运行的框架。那么何为轻量级，何为重量级？其实很难给出准确定义，有人开玩笑说“将技术规范文档放称上称一下，超过一斤的就是重量级，否则就是轻量级“，我的理解实际上就两点——无侵入、方便测试，满足这两点的就算轻量级。

在我看来Spring框架的核心原理就两条——IOC和AOP，基于POJO实现的依赖注入和基于代理的方式实现AOP。通过IOC实现功能模块之间的低耦合（以依赖注入的方式交由容器来管理模块之间的依赖），通过AOP实现功能模块之内的高内聚（以AOP的方式向功能内部注入其所需要的通常的企业级服务），从而达到功能模块的高内聚和低耦合，提高模块的独立性，奠定高质量软件架构的基础。以此为内核Spring作为万能黏合剂，将上述EJB提供的对应用开发有价值的企业级服务（如声明式事务、O/R Mapping、各种池管理等）的各类开源解决方案粘合到Spring中，从而替代EJB这种重型方案并且还提供易扩展、易测试等额外好处。

当然Spring发展到今天，本身已经集成了一大堆各类业务问题的解决方案，使得它成为一个几乎可以扫射一般中小型企业应用中遇到的绝大部分问题的强大武器。这一点还得感谢开源社区，正是因为社区对Spring理念的认同以及认同之后所贡献的各类业务问题的优秀解决方案，这种良性互动造成今天JavaEE领域框架市场上的王者之尊。

 

回到本文标题，为何用它？

看起来一个应用如果什么框架都不用倒像是最简单的，所有技术问题自己实现嘛（也就是重复造*）。但经过实践证明容器是非常重要的，连这都不要的话是过犹不及了（如果你做过一些仅仅使用java原生态技术的项目的话应该会对此深有体会）。有一个容器存在，它可以提供企业级服务（避免二次开发）、一致的服务访问方式、可插拔性、一站式购物体验（找到容器就可以找到容器提供的所有服务）等等。

明确了需要一个容器之后，还剩下一个选择的问题，究竟选择一个轻量级的还是EJB的容器？

EJB容器缺点上面说过了，但EJB有专门的厂商支持（你或者你的客户有足够的Money的话）。而开源的轻量级容器很多，为什么要选择Spring？我的答案除了对于Spring框架理念的认同之外，更重要的一点是它的社区活跃，碰到的大部分问题能直接在网上获得答案。