从架构角度来分析Spring

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

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

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

关于AOP

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

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

再有，Spring其实可以再AOP的基础上加上一些迫切需要的改进，例如上下文的传递，JVM出现各种状况的反应，织入程序对AOP片段的控制和融合等等。

关于IoC

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


感觉Spring在Java反射的基础上做的事情还是稍微有些少，应该再挖掘一下，给上层开发者带来更大的方便。包括类或包的动态加载甚至动态寻找，甚至可以包括使用beanshell来自动编译，这就和动态语言有了更多的结合。甚至拓宽一点来想，可以和C语言写的构建更无缝的结合起来（我这里引而不发，就不深入写啦）。


关于复杂度

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


怎样降低复杂度呢？

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

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

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

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

其实，这些看法也来源于我上一篇“轻架构”的概念，架构应该很轻，实现要厚重，这是一种比较符合自然规律的架构方式。

评论

9 楼 windshome 2014-01-10  

我2004年接触到AOP的时候，的确AOP和IoC没有关系的。

Aop也就是代码织入嘛，说白了实现上和设计模式中的模板模式也就是一步之差。但是思想上和模板模式就有了很大的分界。

8 楼 Tyrion 2014-01-09  

finallygo 写道

windshome 写道

finallygo 写道

ioc是为了更好的aop,怎么会没有关系呢?

我才疏学浅，看不出这两者之间的关联是什么。

很简单,比如你现在不使用ioc的话,你要怎么去实现aop呢?

这是两件事情啊，aop的实现方式多了去了，从最原生的jdk的接口代理到cglib到语言层面的AspectJ都可以。

7 楼 finallygo 2014-01-09  

windshome 写道

finallygo 写道

ioc是为了更好的aop,怎么会没有关系呢?

我才疏学浅，看不出这两者之间的关联是什么。

很简单,比如你现在不使用ioc的话,你要怎么去实现aop呢?

6 楼 windshome 2014-01-09  

finallygo 写道

ioc是为了更好的aop,怎么会没有关系呢?

我才疏学浅，看不出这两者之间的关联是什么。

5 楼 windshome 2014-01-09  

finallygo 写道

ioc是为了更好的aop,怎么会没有关系呢?

请指教。AOP是为了关注度分离而衍生的“面向方面编程”，IoC是为了避免编码中强依赖关系，导致代码耦合过于紧密而导致的不易变化和扩展而导致的。

4 楼 finallygo 2014-01-08  

ioc是为了更好的aop,怎么会没有关系呢?

3 楼 fly_hyp 2013-11-04  

我的很好。

2 楼 windshome 2013-09-06  

答提出问题的老兄：

AOP的不当使用，使代码失去主线索，成为“方面”的分割。而主线索代表了一个产品代码中所围绕的主要概念。

“方面”应该是为“线索”和“流程”服务的，在AOP之前的编程范式中，流程会调用好多基础包完成自己的流程，而AOP之后，无须再调用，自动织入。

其实想想，AOP的织入和普通用的模板模式何其相似，模板模式用的好，效果也非常接近AOP了。你说“业务过程无须再考虑日志的记录，所以日志做成单独的方面比较好”，但是为什么日志不是业务过程要考虑的？什么时候记日志，记什么内容，当然且理所当然是业务要考虑要设计的，这是我的理解，和现代AOP架构部一致的地方。

作为一个设计者，你的每个业务流程，考虑参数检查否？考虑权限判断否？考虑数据库交互否？考虑记日志否？当然都应该考虑，这是完整的过程。可以由上层设计师做成模板模式，由代码实现者只做数据库交互就可以，但是设计上是有全流程的设计的。

那么，如果只对无关紧要的部分使用AOP是否可以？当然是可以的，但是既然已经无关紧要，那么用不用什么心的架构，意义和价值都不大了。


另外，之前的设计过程，某一个业务流程出现错误，只需找特定的一个或几个人负责，现在一个业务涉及到整合的若干个方面，出错了再也要找更多的人来处理，这是小事，但是很烦。

1 楼 Tyrion 2013-09-06  

IOC和AOP要解决的是JavaEE应用中两个不同方面的问题，其实Spring并没有提供任何新的思想，只是把原来就有的理念在Java世界里实现出来。还有一点就是成名较早，同时期不只它一个轻量级容器解决方案，但他在社区的推动下一直流行到现在。

不只你这篇博文中AOP的缺点究竟是什么？性能方面，JDK早期版本用反射来实现的可能有性能问题，但JDK5之后这点不会成为瓶颈。
阁下是否指这种面向切面的思维方式的过度使用？与原来的面向对象编程思考方式的冲突？