采用Rail的理念设计一个Java开源框架（GreenTea）

写Java程序写了4年多，用过的框架也在五种之上，了解的更多一些。初入公司的时候，使用的是Sun公司的PetStore框架，那时的J2EE正是方兴未艾之时。这个架构很复杂，但是当时的感觉是很神奇，暗暗地佩服能写出这个架构的人。当时不能全然的理解，只是兴奋的、不知疲倦的完成一个又一个功能，一层又一层的追踪各个Bug。在工作的前两年里，我一直在使用这个框架，但是完成的项目都不成功。它太复杂了、学习曲线很陡峭；它的层次和结构很明晰，但是层次过于繁复了，调试起来特别困难。我想很多用过的人会有这样的感觉。总而言之，它不太适合做项目，但是其中的很多思想还是值得借鉴的。
后来接触了一个比较大的项目（多于100个开发人员），据说整体的架构也是由一个著名的大公司设计的，当时给我的感觉是豁然开朗，实用的框架应该是这样的！它给应用提供了一个平台，而不是束缚；它应该足够简洁而不失灵活......

在此之后，为公司设计过两个框架，第一个其实是在Struts和PetStore的基础上拼凑修改而演化过来的；第二个是个异构的，前端采用富客户端的框架。

去年的大部分时间里，我在使用以struts、hibernate和spring组合框架完成项目；目前，我看到的和了解的项目多是这些框架的某些组合形式。给我的感觉是，很累！我要照顾struts、hibernate、spring的配置文件；当我修改时，我也修改一层又一层的接口；有时内存会莫名其妙的消耗、有时系统反应迟钝......，至于学习曲线、复杂程度问问新人便知道了。

"Don't repeat yourself"，计算机能够做的事情就应该由计算机来完成。当你打开struts、spring、hibernate的配置文件你就会观察到，这些文件的内容大部分是相象的、类似的、有规律的，这些事情应该由程序来处理。我们做业务抽象层和DAO层，我感觉大部分是因为spring的影响，它需要我们这么做。但是，这些可扩展性是我们需要的么？一个项目有多大的几率将持久化层从Hibernate方式切换到EJB的方式呢？如果真的需要切换，是在切换时在进行抽象的处理代价大呢还是我们总在维护这些层次的代价大呢？

对Rail有了一些了解后，我发现这才是我应该做的事情。我们需要快速的开发出应用，摆脱繁杂的配置文件，使维护的工作更简单，开发应用时只关注业务逻辑...。目前这个框架已经基本成型，其基本宗旨就是摆脱配置文件的束缚，简化层次结构。我将其放在google的开源项目上，如果有人对此感兴趣，希望我们能够协作开发；也希望能得到一些中肯的建议或者意见！
项目的源码和文档如下：http://greentea.googlecode.com/svn/trunk/，目前还处于较为零乱的初级阶段。