还在学校时，我刚学习java大概一年左右，那时听到最多的就是java的重点是J2EE，而J2EE的核心是EJB。于是我大约花费了一个学期的时间来系统的学习了J2EE的相关东东，并用EJB实现了一个学生订课系统。这套基于JSP + EJB + WEBLOGIC + ORACLE的系统刚刚运行起来时真是非常的有成就感，感觉终于掌握了Java的核心了。
后来不久，我就去到一家公司实习，去了以后发现那里的前辈们都在谈论什么DI和IOC的新名词，他们正在把老一套的OA系统从基于EJB的架构升级到一套全新的框架上，而那套框架包含了一堆我完全没听过的新名词。然后有前辈给我推荐了一本书叫《Without EJB》，看完后让我十分沮丧的是我刚刚练熟的Java核心技术EJB还没机会出手就已过时了。
从那时起，我开始知道了一个名词叫Framework，然后学习了一整套的基于开源Framework的系统开发方式。知道了为什么EJB是重量级的，而Framework是轻量级的。当时EJB已步入暮年，Framework的春天开始来临（最有名的Framework正好叫spring），如今Framework已经枝繁叶茂，遍地开花，如火如荼。
我们知道Framework很多时候就是一个或一些jar包组成的，在最近接触到的一个web应用系统中，我尝试去拷贝一份工程目录时意外发现居然有接近500M大小，再去看依赖的jar包多达117个之多，着实吓了一跳。在500M的工程目录拷贝的进度条慢慢移动中，我就在想如今的系统开发是不是患上了Framework依赖症。我相信没有人能搞清楚为什么这个系统需要117个jar包之多，我们只知道为了完成一个功能，我引入了一个开源框架，而这个框架又引入20个它的依赖包，然后框架帮我解决了大部分脏活，仅此而已。如果我们运气好，这些框架的质量非常之高或者我们的系统从来没多少人用（程序员的悲哀事之一），因此这些框架在干脏活时从来没出过问题，我们也不需要了解它们怎么去干的。但如果不巧，某个框架在哪天在某些情况下出现了问题，此时我想总有人会惊慌失措了。
我承认框架从它诞生起，是帮程序员们解决了大麻烦的，大大提高了生产率。但如今很明显是一个框架鼎盛的时代，同一个问题总能找到几种或十几种不同框架来解决，如何选择、了解、取舍框架占用了我们大量的时间，而忽视了我们要解决的问题本身。框架从解决一个特定领域问题微小代码集合开始发展到提供解决方案、限定编程模式、绑定概念，并尝试不断的通用化来扩大适用范围（抢地盘？），这样的框架自然不断的变得庞大、复杂、高度抽象，同时提高了其使用成本。到底轻量级还是重量级也许到了今天不该再以容器的独立性为标准了。
在现实的编程的环境中，我其实不太喜欢带着通用称号的框架。
通用意味着至少要适用于大于2种或以上的场景，场景越多我的选择和取舍成本越高。
通用意味着抽象度更高，不抽象没法通用啊。而现实是越高的抽象度，越不容易被理解，例如人生活在三维世界，理解三维空间是直观的没有抽象，理解四维空间稍微困难点，那五维或以上基本上一般人已经理解不了。在科学领域以什么论结尾的学科通常都是高度抽象的，比如相对论、数论、信息论，能理解的人都很少、精通的自然更是凤毛麟角，而编程活动介于工程和工艺领域，贴近于现实问题，完全不抽象则凌乱重复、抽象到高一层通常恰到好处，兼顾灵活、小巧、透明和易于理解，没有任何程序能做到真正意义的通用，让人更容易搞清楚程序的适用范围和条件，比通用有意义的多。
这时，让我想起了小时候看的一部漫画《圣斗士》，程序员像圣斗士，而框架就是我们背负的圣衣，没有了圣衣战斗力就急剧下降。
打不死的星矢说明了，小宇宙最重要，圣衣不重要，尝试脱下那些沉重的圣衣，去锤炼自身的小宇宙。