再论Spring的用处(mvc 框架、spring、hibernate应用有感)

从2012年到现在使用spring已有4个年头。
记得当时发了个贴http://www.iteye.com/topic/865387
还吵来吵去的。

现在再看看这些框架的作用，其实我所用到的其实是简单的思想，即：

积木式的程序设计

我一直研究OO方法，现在可以确认，mvc、spring、hibernate，在OO的层面，大多数情况，只是用到了封装，这是简单的OO应用。

所谓贫血模型，不过是把经过封装的过程，硬往OO上靠而已。那已不是OO，用好了可以构建出封装良好的积木，在一定范围内重用，同时带来软件易于修改、分工、稳定等好处。

那不OO就不好吗？

对于mvc、spring、hibernate 的体系。在应用的层面，显然能做到积木式的程序设计，就行了。再弄其他的就是画蛇添足了。

那OO没用吗？
当然不是，在具有复杂事物表示的环境里，对事物本身的抽象是解决问题的关键，OO是必然。

那Spring有什么用处呢？
1. 提供通用的现成的搭建积木式软件的解决方案。
2. 提供辅助工具。

IOC和AOP为实现上述目的，提供了支持。

在这里回答一下4年前我提的问题：

1）不用Spring时，你强烈的感到需要IOC和AOP了吗？
不会感到需要IOC和AOP的，因为这些是实现积木程序设计的手段，它不是直接可用的方案，而Spring是一个利用IOC和AOP搭建积木式程序的方案。

2）程序不用Spring的影响是什么呢？
1. 软件架构方案需从头做起。 项目人员需从头学习。
2. 缺少的Spring的辅助工具，需要开发。

以前我提到的Spring的软件解耦的作用，其实质是搭建积木式的程序。用解耦来描述太宽泛了，实际上解耦的问题无处不在，而Spring只是用在程序架构上的解耦。

mock 软件测试，在需要时，是可以使用的。（目前未用过）

先说OO,你也说了,在具有复杂事物表示的环境里OO是必然,但是现在多数情况下,都是一些简单场景,一般都是前端输入数据,后端保存,中间转换都很少,基本没有业务逻辑,只是硬往OO上靠,最终成为了只具其形,不具其神的假OO.
不用spring其实也没啥,只是习惯了而已.真的有那么多场景需要用到IOC吗?
感觉真的没有那么多场景真的需要IOC,spring管理对象有多少是真正发布以后需要配置的?
多数情况下都是用spring省得自己new对象或自己实现一个单例而已.如果真的需要配置,那么,spring的配置文件也不会被标注替代了

是的，其实差不多就是这样子

你前边说的我基本赞同。

不过我还是认为 Spring 很重要。Spring的配置文件，是程序的一部分，本来也不是给发布后修改用的。
标注只是比配置文件更方便，本质上和配置文件没区别。

new对象和取代单例，只是Spring的基本内容。更重要的是它在软件架构上起的作用。它是一个优良的架构，提供了灵活的扩展性，最明显的是“声明式事务”，这是AOP的典型应用。

分享一点自己实现程序架构的经验：需要想办法避免“连接池”死锁。