目前，看到在OSC中，不少人在写框架，比如：JFinal，比如Smart ，比如Hasor等。
可能大家都集中在一个轻量上作文章，这里我想就轻重做自己的一点感想，不一定正确，就当扔个砖出来，大家请放心大胆的抛玉出来，一起讨论。
曾几何时，Spring之横空出世，大家都是欢呼雀跃，为啥呢？因为Spring轻量。为啥轻量呢？看看EJB就知道了。那为什么EJB就重了呢？主要的原因就是大家必须围绕着EJB转，如果离开了EJB，就玩不转了。这个重就体现在，开发模式与EJB绑定之谓重，运行环境与EJB环境绑定之谓重，对EJB深度依赖之谓重。
而Spring当时为什么就轻了呢？当时Spring的采用了无侵入式设计，从而使使用它的人感觉不到它的存在，但是又能享受到它的好处。所以，就如一楼春风吹向广大深受EJB荼毒的程序猿们，于是Spring火了，Spring得到了非常大的应用与推广，甚至可以说占据了统治地位。
鄙人和Smart作者黄勇也通过QQ沟通过，感觉他的思想、理念都非常不错。看了哈库纳的博客，也为他的一些想法所惊叹。
稍有不同的是对轻量级框架的理解稍有不同。在以上作者的理解中，都期望依赖尽量少的框架，框架的容量尽量小。说实际的，这个目标也是本人所追求的。实际上，所有期望做平台的人，也都会这么想，毕竟：完成同样的功能，为什么不用更小的呢？更小的代码一般来说都代表性能更高，维护量更小，里面的遗漏缺陷更少。
但是，在另外一个方面，我也看到了以上三个框架都大量的采用了注解来实现相应的功能。注解与XML各有优缺点，这个道理大家都明白，注解之优势在于浑然于一体，XML之优势在于无侵入性，工具的可处理性更强，等等。
曾经有一个朋友给我留言说：你的Tiny框架依赖了Spring，就不可能是“tiny”的框架了。这在一定程度上也代表了相当多的人的一种观点。
在此我给出我对于轻量级框架的定义：
所谓轻量级框架，就是能帮使用框架者解决尽可能多的问题的同时，尽可能少的对使用者构成侵入性影响。
如果非要给出一个公式的话，那就是：轻量系数=解决的问题/侵入程度。
说的通俗一点就是，你给人家解决的问题越多，而对人家造成的干扰越少，那就越轻量。
每个框架构建者可能都要考虑这样一个问题，如果有一天，别人的项目要向你的框架迁移，需要付出多少的迁移成本？如果有一天，使用你框架的项目要向别的框架迁移要付出多少成本？
实际上，这两项的成本不太可能为0的，但是应该尽量的小。如果说，不管怎么样，这两项的工作量都非常大，那你这个框架就不能算是轻量级框架。
再换句话说如果，这两个成本比较高，别人在决策的时候，就会非常小心，除非不得已，不会使用你的框架，或者不会迁移到你的框架上来。
所以，框架轻重之我见，判定的标准与jar包大小无关，与依赖的第三方包的大小多少无关，只与框架能解决的问题的能力及侵入程度相关。
