Simplify the Best：轻量框架
板桥里人 https://www.jdon.com 2006/11/13
很多人比较迷惑轻量框架（lightweight framework）的定义，以板桥个人看来，轻量一词其实没有一个严格定义，它只是反映我们对好技术的更易于使用一种要求：Simplify the Best。
一、回顾历史
我们首先回顾Java的发展历史就会明白：为什么现在大家对正常的轻量要求如此迫切：
让大家对正常轻量如此迫切要求的主要压力来自于EJB，注意，这里并不是说EJB不好，而是太好了，
属于Best，但是只注重Best，忽视易用，或者说没有来得及进行易用。
在EJB技术之前，我们开发一个复杂Java企业应用系统时，会在代码设计中充满各种底层技术的味道，或者说，那时的Java更象C++，Java企业应用开发者需要学习更多更全面软件技术才能动手编程。EJB则将很多底层技术：缓存、池、安全以及事务封装在特别的EJB服务器中，从这点上解脱了开发者的工作。 在这个时代，Java技术重心就在于J2EE服务器，或者称应用服务器，中间件服务器。各个厂商 争相研制功能强大，能够支持几十台集群计算的EJB服务器，并依此为荣，Bea的Weblogic是这方面的佼佼者。
但是，EJB问题同时也暴露出来了，在EJB2以前版本，复杂的XML配置；各种稀奇古怪的调试运行问题使的EJB开发调试变得非常不容易，开发者经常在错误信息中迷失方向。
这时，除了一个熟练EJB开发者以外，对于普通开发者，EJB2以前版本的开发变得沉重Heavyweight，Java世界弥漫着一种沉重而不满的氛围，因为EJB是各大厂商联合起来制定的工业界标准，对其质疑可以说是对主流文化的一种反叛，但是历史总是在否定中前进。
首先打破这种沉寂的是Spring，Spring打着轻量简单极具号召力的口号横空出世，可以说恰逢其时，很快赢得了广大开发者的响应，虽然这场without EJB运动中有时过于极端，但是至少表达了大家对EJB 2的不满， 虽然在这个EJB阵营，聚集中软件领域最顶端的厂商权威：IBM BEA Oracle SAP SUN等，但是开发者还是坚决地说NO，并且进行了自己的选择。
当然好戏最终以轻量化的EJB3.0出世而收场，但是我们还是很有必要思考一下：我们开发者到底需要什么样的技术？这样才能在瞬间变化的发展潮流中坚持自己观点，而不是人云亦云，迷失方向。
二、轻量框架特点
轻量本身有时是一个非常感性的词语，并且随着技术发展不断更新，举例：对于一个初中生，加法计算是很 轻量的；可是对于幼儿来说，则可能重量的。轻与重可能因开发者而异。
但是，让科技变得更简单易用的方向是没有错的，总的来说：一个轻量化框架应该使得开发者将更多精力 集中在业务开发上，而且多快好省地完成稳定而且灵活的产品开发。
总之，轻量框架需要体现Simplify the Best，注意在这个定义中，首先是Best，然后才是简化，这才体现大道至简的原则。
Best在软件中意味着良好的设计，意味着灵活性，意味着软件的高质量。企业软件必须容易维护和发展，这样才能帮助企业成为百年老店，在企业IT长时间发展中，硬件设备可以通过资金投入更换，但是软件只能在原来基础上拓展，而不能彻底推翻重来，但是如果原来软件的拓展性很差，就造成了“巧妇难为无米之炊”的痛苦。
现在，面向对象分析设计思想无疑被认为可以将软件做得Best一种方式，在OO思想中，主要解决两个基本问题：如何建立业务对象？对象关系如何组织？2004年Evans发表得DDD理论（Domain Driven Development）是企业对象建模的经典著作；可以说为如何建立
企业业务对象提供实践方法支持；而GoF设计模式则是最早提出如何更灵活组织对象间关系。
在简化方面，Java世界提出的POJO思想，可以说是简化方向，POJO实际就是普通老的JavaBeans，这是相对EJB 提出的，因为在EJB2中，JavaBeans或Class不再是自由自在的独立类，它必须依赖附属于EJB框架，我们不能 因为需要集群功能，而放弃原来简单好用的JavaBeans。具体来说：轻量化的企业Java框架是使用POJOs来实现数据访问和业务逻辑，没有其他隐含的类或接口需要继承 或实现。
轻量框架一个特点是：Ioc或称Dependency Injection (DI)，通过Ioc模式的使用，所有的POJO可以 实现最大化的松耦合，具体详情可了解Ioc模式/DI。
Ioc/DI是所有轻量框架的一个共同特点，不同的只是具体Ioc/DI实现方式不同，DI使用轻量化的框架容器将服务或其他对象注射进入POJO. 这样，所有对象实例的创建和管理由容器实现，这样，大大减轻了 开发者的工作。
轻量框架在Ioc/DI实现上具体不同主要表现为注射方式：是否AutoWiring，也就是由框架容器自动寻找类与类之间依赖关系，而不需要在代码或者配置文件中，指定是谁调用谁。这样，可以杜绝底层琐碎事务，彻底解放我们的思想。试想：一个普通系统有200个POJO类是正常，在开发调试中，经常在这些类之间调换变化，使用AutoWiring轻量框架，我们只要移动这些类的接口就可以，而不必涉及过多代码或配置变动。
网友zhaow8810说： Ioc的过人之处，使得设计非常灵活有些组件化的感觉。构建系统就像搭积木，这时你可以把所有的模型和服务统称为Service，你提供的Service的多少可以决定你的系统具备哪些功能。而这些Service就相当于积木实体，而Service之间的关联相当于积木怎么摆放，这就看你自己的想象力有多丰富，积木搭建的漂亮，说明你的业务层做得比较完善。
Ioc将原来纠缠在一起、铁板一块的构件模块分割成一个个相对独立的类，当我们将建造一个大厦细分为沙粒时，我们就可以使用沙粒来组合任何一个建筑了，这体现了未来面向构件化编程(基于组件编程)的一个发展方向。
三、轻量型框架
前面我们已经总结，Ioc/DI是所有轻量框架的一个共同特点，不同的只是具体Ioc/DI实现方式不同，目前，Java世界轻量型框架层出不穷，从当初的Spring 到HiveMind以及JBoss Seam，
JdonFramewok也是符合轻量框架特点的一个国产开源中间件产品。可以说：轻量型框架是未来构件架构发展方向。
相关文章
Lightweight Java Enterprise Application Frameworks: JBoss Seam
表现层框架、业务层框架、Tapestry VS Spring
Ioc模式(又称DI：Dependency Injection)
更多框架专题