也谈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框架理念的认同之外，更重要的一点是它的社区活跃，碰到的大部分问题能直接在网上获得答案。

评论

7 楼 Tyrion 2013-09-06  

lvwenwen 写道

lz,博客园讨论spring的链接发下

呵呵，是个搞.net的人说的，http://www.cnblogs.com/COIN/p/3261636.html

6 楼 lvwenwen 2013-09-06  

lz,博客园讨论spring的链接发下

5 楼 windshome 2013-09-06  

对Spring，甚至Java世界目前的做法我抱慎重态度，但是又希望这个东西能越做越好。

如果Spring能够抓住自身的重点，那么还是大有发展的。

IoC和AOP是毫不相关的两个事情，揉到一个框架里叫Spring，有点白菜拌花生米的感觉，最好是分裂成两个框架来做。

关于AOP

我甚至觉得，Spring拿来了别人的AOP来搞，其实很没有意思，并且对AOP没有什么大的发展和贡献。只是因为Spring名气大，很多人因为Spring接受了AOP，但是AOP的弊端是什么？谁思考过？

回想十年前，刚刚看到AOP的概念，我也很兴奋，打算采用，但是考虑了一大圈，还是老老实实没敢采用，就是考虑到了它的弊端。


关于IoC

IoC看上去很概念化，但是究其实质，也就是封装了Java的反射机制。在10年前，我刚刚开始做架构时，做的第一个产品架构，就大量使用了反射机制，的确给带来了很大的架构上的灵活性，做到何种程度了呢？其实也就是在配置中规定了很多全局性的对象的创建方式（之所以第一次看到Spring的介绍，感觉怎么和我的那个产品架构很相似，不过因为我只考虑自己产品的情况，无须考虑通用性，刚开始也无须考虑太多兼容性，所以比较简单，相反，在安全性和健壮性上考虑自问比Spring要多一些）。


感觉Spring在Java反射的基础上做的事情还是稍微有些少，应该再挖掘一下，给上层开发者带来更大的方便。


关于复杂度

我觉得Spring虽然号称轻量级，但是实际上还是过于复杂。因为很难描述清楚这个东西（兴许是我才疏学浅，大家不要笑我，因为之前不做J2EE方面，所以要允许我慢慢摸索），我感觉，降低复杂度是Spring的一个很迫切的事情。


怎样降低复杂度呢？第一是把IoC、AOP等不同的东西分离。因为这本身就不是一件事（不要说都是为了简化业务逻辑啊，这是架构的最终目标，不是一个架构或部件的实际任务）。

分离后，应该是分为架构层和工具层两种。这两个层应该由不同的两个小组来完成，实在不行的话，也应该当成不同的两个任务或项目来做。

架构层的目标是建立一套在处理业务时，犹如身使臂，臂使手一样灵活自如的机制，使控制流和数据流在其中运转。架构层又分为IoC的架构和AOP的架构，如上，也应该当成两个不同的任务来做。

工具层没有什么好说的，为了支撑框架的运转，需要一部分组件工具，为了辅助开发者，需要更多更多的工具，但是这个应该分开。支撑框架的工具，可以由开源组织来设计开发，辅助开发者的工具，就不要掺和太多，实在需要的话，应该当做单独的任务或项目。

4 楼 Tyrion 2013-08-16  

freezingsky 写道

之前面试也遇到过这样的问题，也是问为什么觉得spring好？当然，我不会从那位大师那本书的内容里搬出一堆。但回答下来大致是如下几点：
1.非侵入式。这对于开发不管是基本web还是桌面的来说，可以摒弊运行环境的影响，只关注于自己代码逻辑的实现。
2.IOC和AOP。然后回答一堆关于什么叫IOC，AOP以及二者有什么用之类的问题，答案的内容基本上也集中更方便业务方面的考虑，而将一些验证或者是logger方面的东西交给AOP来完成，大致云云。
3.spring中设计到的相关的设计模式。往往这里会涉及到谈论相关模式的使用场景，甚至会要求画出相关的类图等UML方面的内容。
4.spring用过了，是否了解IOC和AOP的实现原理？如果没有spring，能否自己设计一个简单的IOC容器，以及AOP的简单实现？这方面的东西如果平常喜欢研究的话，很容易就能回答出来，并且也能用伪代码描述出大致的过程。
5.由spring的问题，往往会引申出所谓的struts2，hibernate,mybatis之类内容。特别是hiberante方面，容易涉及到一些所谓的优化内容，以及为什么这么优化以及优化方面与JDBC的关系。
剩下的，留给其他人补充。。。

其实这类问题本就见仁见智的，看你是站在一般开发人员还是架构师还是项目经理的角度，由此所关心的框架在实际项目中的权衡利弊的侧重点是不一样的。

3 楼 Tyrion 2013-08-16  

lvwenwen 写道

那位大师那本书的，那本书啊?

《Expert One-on-One J2EE Development without EJB》和《Expert One-on-One J2EE Design and Development》

2 楼 lvwenwen 2013-08-16  

那位大师那本书的，那本书啊?

1 楼 freezingsky 2013-08-16  

之前面试也遇到过这样的问题，也是问为什么觉得spring好？当然，我不会从那位大师那本书的内容里搬出一堆。但回答下来大致是如下几点：
1.非侵入式。这对于开发不管是基本web还是桌面的来说，可以摒弊运行环境的影响，只关注于自己代码逻辑的实现。
2.IOC和AOP。然后回答一堆关于什么叫IOC，AOP以及二者有什么用之类的问题，答案的内容基本上也集中更方便业务方面的考虑，而将一些验证或者是logger方面的东西交给AOP来完成，大致云云。
3.spring中设计到的相关的设计模式。往往这里会涉及到谈论相关模式的使用场景，甚至会要求画出相关的类图等UML方面的内容。
4.spring用过了，是否了解IOC和AOP的实现原理？如果没有spring，能否自己设计一个简单的IOC容器，以及AOP的简单实现？这方面的东西如果平常喜欢研究的话，很容易就能回答出来，并且也能用伪代码描述出大致的过程。
5.由spring的问题，往往会引申出所谓的struts2，hibernate,mybatis之类内容。特别是hiberante方面，容易涉及到一些所谓的优化内容，以及为什么这么优化以及优化方面与JDBC的关系。
剩下的，留给其他人补充。。。