从架构角度来分析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的架构，如上，也应该当成两个不同的任务来做。

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

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