SpringFramework is all about Enhanced POJO

假如有人问你“什么是SpringFramework”？你能用一句话讲清楚吗？
呵呵，这似乎是个很难的问题。因为Spring不象Hibernate或Struts那么单纯，只要简单地说：Hibernate是一个O/R Mapping Framework, Struts是一个MVC Framework就可以了。
有人会说Spring是个Application Framework，但application Framework这个概念似乎太广泛了。也有人会举例来说：SpringFramework里包含一个IOC容器，一个AOP framework，还有数据访问架构，还提供了简化的事务处理etc.，一下子可以说出一堆，呵呵，太不简炼了。
在我看来，Spring is all about enhanced POJO。Spring的魅力在于它将POJO的装配与POJO的代码分开。

传统的软件开发经常会遇到以下问题：
1．怎么设计类与类之间的关联，在什么时候初始化相关联的类？
2．怎么进行事务处理，怎么进行logging？
3．怎么访问JNDI, 怎么访问Web Services, 怎么发Email, 怎么进行定时任务调配?
传统的软件开发方法的答案分别是：
1．用Strategy模式和静态工厂将对象的创建和具体的类实现分离。但是无论如何，你必须自己负责自己创建这个对象，不管是工厂里还是在相关类里，总是在某个地方我们代码和相关的类紧密耦合了。要替换我们的实现吗？Sorry,我们必须修改我们的初始化代码。
2、显式在代码里Start Transaction, 成功了之后commit transaction, 出现异常时roll back transaction。这里的问题时，当这些事务处理的逻辑和我们的数据访问逻辑耦合在一起时，我们又失去了灵活性，同时我们的代码功能模块也变得不清晰了。要把JTA的transaction的代码替换成local transaction? Sorry, 我们必须替换代码中所有的事务处理逻辑代码。有段代码在某个环境下需要事务处理，另一种情况下不需要？Sorry, 没办法，我们必须新建一个方法，一个叫做fooWithTransaction, 另一个叫做fooWithoutTransaction。
3、显式地在代码中写远程访问,得到接口, 再显式访问。好多的重复代码啊！假如我们想把JNDI替换成本地接口的访问, Sorry，重写你的访问代码吧。

所有的这些都是因为一个原因：POJO的责任太多了，它不但要负责业务逻辑的处理，它还要做根本不属于它管的初始化、资源管理等逻辑。
假如有一个大的工厂，我们把产品的毛坯一个只有业务逻辑的POJO放进去，经过一道道的生产线， 这个生产线出来的就是我们的成品---Enhanced POJO。
对象之间的关联? 我们不需要知道, 我们只知道这个生产线出来的产品已经有了这个功能。要替换成另一个对象的implementation吗？稍微改一下配置文件就行了，跟我程序的逻辑没有任务影响。
事务处理？工厂已经帮我们准备好了，我不关心它用了AOP还是啥,我只知道我们的Enhanced POJO已经有了这种能力。
访问JNDI还是Web Services还是本地接口？我根本不用关心，工厂已经帮我准备妥当了。

这就是我们的Enhanced POJO，它的魅力在于将不属于POJO的职责转交给工厂。而工厂组装的逻辑与实际的逻辑完全分离的。它给我们带来了具大的简单性和flexibility。
也许有人会说Spring的MVC和JDBC framework不属于Enhanced POJO。要记住Spring MVC的bean就是普通的POJO, 经过工厂组装出来的Enhanced POJO使它具有了处理Web request的能力。 JDBC framework的POJO不是从工厂里组装出来的, 但是它也是通过callback interface使POJO具有了资源初始化、释放和异常处理的能力。
总之，IOC、AOP和callback interface等让POJO达到了以前EJB无法达到那种超能力。这就是扩展性、灵活性简单性都无可比拟的enhanced POJO。

Spring的核心是DI容器，Spring的威力大多源自DI容器，你的讨论没有错，不过，你的讨论只能算是一个中间层次的讨论，上下还有许多余地。

向下，深入DI容器的实现，Spring DI容器只提供了组件组装的功能。AOP，也就是所谓的声明性的基础，完全是通过DI容器的扩展（FactoryBean）带来的，而不是DI容器的基本功能。

向上，Spring有着一个很广阔的目标，除了J2EE的基础容器，大部分领域它都涉足了，只不过有些别人做得好的，像OR Mapping，它采用的手法是集成。

所以，单以Enhanced POJO论Spring，似乎有些小看了Spring。

我倒认为，以Enhanced POJO来论Spring，已经有点高看了Spring了
一个Enhanced POJO能包含的内容已经太多了

并不是说DI和AOP就不那么重要，只是这与DI和AOP属于不同的视角

可能是我们看待问题角度不同吧！

我说小看Spring，是指Spring已经超出我们所说的技术层面，它的宏伟蓝图绝非Enhanced POJO可以涵盖。

我没有太理解你的说法，为什么Enhanced POJO就高看了Spring，希望听取一下你对于Enhanced POJO和Spring的理解。

以楼主论事的角度，Hivemind也应该算有一种Enhanced POJO的味道。

同意dreamhead， 我觉得DI容器应该可以算是所谓的“银弹”（当然要看不同的应用），可以极大的提高我们的开发效率。spring正是在DI+AOP技术就把我们日常开发中所要的重复性劳动简单解决了。

将DI视为银弹有些夸张了，它只不过改变了我们对于组装系统的看法，让我们系统的结构看上去更加清楚，最终的代码还要靠我们自己来解决。

Spring的核心是DI容器，想要理解Spring的话，一定要深入的理解DI的思想，当然，这里指的是技术层面。

其实是大家理解的角度不同。我的理解是从广义上看，DI也好、AOP也好、用CallBack interface集成ORM或JDBC等也好，都可以视做对POJO功能的增强

这篇帖子应该年年讲月月讲啊, 顶一下.

xiecc进一步总结下Spring 提供哪些Enhanced服务,然后畅想下我们还可以enhanced哪些服务吧. 现在Spring 1.3想象力有点下降的说.

经常听有人说spring就是个胶水，它能把我们用的东东像拼玩具一样拼起来。