jello框架V1.6（以下简称框架）是一个开源的基于AOA技术的java web应用程序框架，它包含了一些独特的观点如零配置、BCP模式、DMM持久化技术等等，支持快速的web应用程序开发。更多内容请参见以下地址：
http://sourceforge.net/projects/jelloframework/
http://blog.csdn.net/yzwgh/archive/2007/01/16/1484728.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/12/1480754.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/12/1480760.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/11/1480412.aspx当然，jello框架的推出不是为了颠覆现有的WEB应用的开发模式，而是为了给WEB应用的开发者提供另一种架构模式，同样地，jello框架也不是struts+spring+hibernate这样的流行模式的终结者，而是陷入struts+spring+hibernate泥潭的中小型应用开发者的另一个轻量级的选择。笔者所在公司曾开发了一个自用的视频门户的运维项目，当时的架构师理所当然地采用了struts+spring+hibernate这样的流行架构来构造应用，其实项目并不大，却是一个典型的成长型的项目，随着业务需求的不断变更，项目很快陷入了泥潭，部分不堪其扰的开发人员的离职更使项目状况雪上加霜。当时的架构师以为采用了流行的架构项目就必然会健壮且易于维护，结果由于缺乏必要的规范，项目的层次划分杂乱无章，业务逻辑时而在service层实现，时而在action里面实现，时而在dao层实现，更有甚者居然直接写在JSP里面，配置文件被维护得晦涩难懂，各人有各人的风格，有的很简洁，有的又非常精巧，事务权限等配置一层套一层，加上缺乏必要的文档，以至于当项目到了笔者手上时，几乎可以认为是没有任何价值的一座代码迷宫，后来的开发者都声称根本没有办法看懂前人的代码，幸好需求文档完好无损，项目功能也不算复杂，笔者果断地决定重新开发。在新的开发进程中，笔者给项目组开发人员引入了jello框架，当然选择jello框架是有很多考虑的：其一，jello框架是一个在sourceforge.net上注册的开放源代码项目，其二，jello框架的BCP模式给WEB应用的分层带来了全新的思路，它的很多特性是专为中小型应用设计的，这比较适合我们的项目，其三，jello框架的面向应用的特性使得编写一个功能模块只需要极少量的代码，而且它的零配置和基于MVC模式的设计使得项目的后期维护变得非常容易，可以说对照需求说明书一个程序员可以轻易地看懂任何一个功能模块的代码，最后，笔者曾参与jello框架的开发，应该说对框架的思想和使用非常的熟悉，不管怎么说，对框架的熟悉程度始终是项目成功的关键因素之一。在项目组成员的共同努力下，项目只用了原来的五分之一的时间就开发完成了，而且运行相当稳定，虽然需求还在不停地变化，但对于模块开发人员来说，再复杂的需求也只是设计时候的复杂，到了修改代码时已经是很轻松了。前段时间项目成功上线，并经受住了百万用户的严峻考验，顺利通过了验收。
http://sourceforge.net/projects/jelloframework/
http://blog.csdn.net/yzwgh/archive/2007/01/16/1484728.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/12/1480754.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/12/1480760.aspx
http://blog.csdn.net/yzwgh/archive/2007/01/11/1480412.aspx当然，jello框架的推出不是为了颠覆现有的WEB应用的开发模式，而是为了给WEB应用的开发者提供另一种架构模式，同样地，jello框架也不是struts+spring+hibernate这样的流行模式的终结者，而是陷入struts+spring+hibernate泥潭的中小型应用开发者的另一个轻量级的选择。笔者所在公司曾开发了一个自用的视频门户的运维项目，当时的架构师理所当然地采用了struts+spring+hibernate这样的流行架构来构造应用，其实项目并不大，却是一个典型的成长型的项目，随着业务需求的不断变更，项目很快陷入了泥潭，部分不堪其扰的开发人员的离职更使项目状况雪上加霜。当时的架构师以为采用了流行的架构项目就必然会健壮且易于维护，结果由于缺乏必要的规范，项目的层次划分杂乱无章，业务逻辑时而在service层实现，时而在action里面实现，时而在dao层实现，更有甚者居然直接写在JSP里面，配置文件被维护得晦涩难懂，各人有各人的风格，有的很简洁，有的又非常精巧，事务权限等配置一层套一层，加上缺乏必要的文档，以至于当项目到了笔者手上时，几乎可以认为是没有任何价值的一座代码迷宫，后来的开发者都声称根本没有办法看懂前人的代码，幸好需求文档完好无损，项目功能也不算复杂，笔者果断地决定重新开发。在新的开发进程中，笔者给项目组开发人员引入了jello框架，当然选择jello框架是有很多考虑的：其一，jello框架是一个在sourceforge.net上注册的开放源代码项目，其二，jello框架的BCP模式给WEB应用的分层带来了全新的思路，它的很多特性是专为中小型应用设计的，这比较适合我们的项目，其三，jello框架的面向应用的特性使得编写一个功能模块只需要极少量的代码，而且它的零配置和基于MVC模式的设计使得项目的后期维护变得非常容易，可以说对照需求说明书一个程序员可以轻易地看懂任何一个功能模块的代码，最后，笔者曾参与jello框架的开发，应该说对框架的思想和使用非常的熟悉，不管怎么说，对框架的熟悉程度始终是项目成功的关键因素之一。在项目组成员的共同努力下，项目只用了原来的五分之一的时间就开发完成了，而且运行相当稳定，虽然需求还在不停地变化，但对于模块开发人员来说，再复杂的需求也只是设计时候的复杂，到了修改代码时已经是很轻松了。前段时间项目成功上线，并经受住了百万用户的严峻考验，顺利通过了验收。
简单点说就是研究如何快速开发设计良好的企业应用的技术，所以说虽然框架的概念比较多，但用起来非常简单，用的过程中你不会感觉到框架的存在，框架为你的应用开发带来了丰富的便利性，而且几乎没有引入新的复杂性，你会感觉就像用jsp+javabean在开发一样，而你开发出来的应用却是基于MVC的。
你说的很对，[不仅仅是框架的事情]，说明跟框架也有关系，现在的框架都太关注于某个技术层面，如struts只关注表示层,hibernate只关注持久层,而spring简单就是一大堆新技术的试验场，除了Ioc和一些支持类，很少听说有人把其他特性用得很好的，而对于企业应用的一些很根本的问题却没有谁能给出相应的模式，比如说分层，jello框架的BCP模式对此作了很好的回答，应该说jello框架是基于JSP2.0的，它只是使用一些技巧化解了仅用JSP实现WEB应用的复杂性而已，并没有加入JSP规范外的新东西。对于新的开发人员来说，不了解jello不要紧，了解javabean,servlet,jsp就足够看懂代码了。
http://community.csdn.net/Expert/topic/5301/5301215.xml?temp=.2561762
如果你的框架好，也没必要这样贬低SSH。
好，既然有人去用。
看看同样做开源的huihoo、buffalo，看看别人的态度
如果纯jsp+servlet 写大的东西
头不大才怪有了框架 我们可以看看 不一定要用阿
了解一下人家是怎么想的
不也是件好事么
http://community.csdn.net/Expert/topic/5302/5302604.xml?temp=.8516809
其实框架并不神秘，有时间的话我将陆续发布解读框架的系列文章，以帮助开发人员更好地认识和使用框架，希望也能给准备自己编写框架的开发人员一些有益的参考。
? to killme2008(为了生态平衡，请保护蛤蟆)有人贬低我的设计？这是我最希望看到的，任何一个优秀的产品都是在别人的指责中成长的。不要光看态度，有时间看看代码，一定有不足之处的，希望得到你的指正。----------------------------
没有，我没用过你的框架，也没读过代码，没资格贬低或者赞扬你的设计。
只是你帖子的标题和态度让人感觉很无奈。
如有得罪，多多包涵
-----------------------------------------
解释一下：这句话的意思是说，我认为一个有责任的软件设计者应该希望别人对他的设计提出质疑，甚至是贬低，至少我本人对此是非常欢迎的，优秀的产品总是在别人的怀疑和指责中完善的。
1.有侵入。
提交时要告知控制器方法method=xxx
还有很多其他的隐藏的全局变量，使用的变量名字太直观，
非常容易造成冲突且没有文档说明。2.控制层间跳转时由于第1点造成再次运行方法3.很多类没有抛出异常，对错误处理造成阻碍。4.持久化层不能处理表间关联。还有几个我不确定的地方，太粗略了就不提了。总结：有设计模式的运用，但对根本性问题的处理太简单了，
还是个玩具，离真实系统差距太远。ssh复杂，他们可是照足相关规范编程的，所以才能建立足够健壮的系统。
举个例子，曾经找过一个国人写的http文件上传类，2xx行代码，
apache的commons-FileUpload则是一个庞大的类库，难道apache是吃饱了撑的？