采用Rail的理念设计一个Java开源框架（GreenTea），希望有人感兴趣，能够协作开发

[albert_zheng66]

写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/，目前还处于较为零乱的初级阶段。

[Saro]

没人顶啊，虽然已有grails(构建于Spring、Hibernate和SiteMesh 之上)了，还是先支持一下，有时间下载来试试。ruby on rails真是让人惊奇的东东，不过说实话，太自动了也未免让人不那么放心....

另外，楼主的大部分理由我并不太赞成....

[albert_zheng66]

首先谢谢各位提供的意见。

我相信任何或者绝大部分框架都是可以通过代码生成工具来处理的；而且，基本上都是生成出来就可以运行。但是，我关注的重点不在这里，绝大部分工程都是修改多于编写，需求变化往往会超过预期。

在Struts、Hibernate和Spring这些配置文件中，存在的一个问题是“耦合点”的问题。比如，一个Hibernate的Bean里面的属性是通过配置文件中的某个标签与数据库中的字段进行“耦合”的。如果一个耦合点在程序里，目前的各种IDE所拥有的良好的“重构”功能可以很好的解决这个问题。即便没有使用这个功能，也可以通过编辑器很快找到因为修改相关耦合点而带来的错误。配置文件的致命的弱点恰恰出现在这里，IDE无法将这些耦合点关联起来，我们只有手工的修改这些“耦合点”，如果忘记了，只能在运行时才能检查到这些错误。这样的耦合很容易引起修改的不便和调试的繁琐！如果增加了一个字段，你的框架有多少个地方需要修改（手工和自动）就有多少个“耦合点”了。

Hibernate的持久化还是非常好的，如果有时间，我会将其提供为框架的持久化机制一个候选方式。但是也不是说他已经很完美了，足够了。下面是从网路上引述的一段话：“最近一年，业界也在反思，到底 ORM 给我们带来的是便利还是麻烦。矛头指向大名鼎鼎的 Hibernate ，纷纷议论其性能问题，大家似乎要达成这样的共识：在业务逻辑复杂的地方用SP，而一般的CRUD还是 Hibernate，就连全球知名的 BearingPoint 也有类似看法。下面一个简单的例子，说明了传统 ORM 工具的弊端。”。如果你做过报表，那么你肯定就不会在这个时候采用Hibernate了。

据我经验，目前很多配置文件是重复的、多余的，可以通过“约定”得到。当然，有些违背“规则”的文件是需要通过配置文件处理。这种情况需要采用典型的“80/20原则”，因此，我希望能够减少这80％的配置文件的维护的工作量。

坦率地说，采用Struts+Hibernate+Spring框架的程序编写起来真的是不轻松，维护起来也是让人头大！

[albert_zheng66]

我对约定的处理是这样的：不做任何的假定，框架能提供的约定都会提供对外的接口，根据具体项目来处理这些约定。

我所希望的框架是可灵活定制的框架（呵呵，远期目标），是给公司的设计人员来用的，他可以选择各种持久化、数据校验、屏幕处理、展示层、事务逻辑的控制等等。但是给程序员编写业务逻辑时，这些对于他来说应该是尽量(不是完全)透明的，好处无须罗嗦了。框架所提供的是一个默认配置。

[pigo]

我没实际使用过ror，单凭自己的一点了解来发表我的看法，
ror适合实现自主的需求， 因为这种约定只能是自己内部的约定，没有语法或者其它的强制规范。
而当面对实际客户的千奇百怪的需求时，依赖默认的约定来实现新的需求就有些束手束脚了。

www.javaeye.com 现在改为ror实现，但是论坛用户反映的大量bug，到现在也没修复完，
固然robbin的时间有限，但是有些看上去普通情况下几分钟就可以修改好的东西，不能简单地以时间不足来作为理由吧？


喜欢ror的人总是说配置文件的繁琐，但是配置文件也可以采取约定的方式阿

比如我的一张表为： userinfo,那么我就可以借助代码生成器生成有关的约定文件，
实现增删查改，国际化，表单校验，分页多条件查询，查询结果的导出，全文检索等等。
然后再次基础上灵活的修改去实现定制的业务逻辑即可。
代码风格模板随时可由自己定制更新，约定编程不应该局限于ror，任何场景都可以进行约定。

以上是个人意见。

[sonyejin]

高手，帮顶

[ziseshatan]

恩 支持 其实无论做的怎么样
国内能有这个想法就十分难能可贵了