一种快速开发的Java Web架构设计和实现

这篇文章写得太粗糙，不想浪费大家时间（原帖删），还是看我后来的改进版吧：
http://www.iteye.com/topic/47085，
虽然它有很大的局限性，但还是值得参考，批判去看它吧。
本文的评论还是值得一读。

Map to Bean可以用BeanUtil附值。
所以数据从页面一进来就可以自动成为一个BEAN，不用写代码的

是的，BeanUtils很有用，但我现在就是想放弃Bean，无论它是Webwork的model，还是Struts的ActionForm，还是Hibernate的PO。

Domain Object在哪？如果没有业务逻辑，那用OOP干啥？用静态类型的Java干啥？拿个Python或者Ruby，从前到后一传，不就了事了？

是啊，确实没有什么OOP概念。
那个Python或Ruby，这不是我决定的，现在客户方要求用Java开发，赶快交活，这是我们的Context。

有一些赞成楼主的说法，毕竟大多数的用户不会关心你用什么技术，这个技术时下火不火。
还有一些不敢轻信楼主的说法，就是这样做真的会比用上框架开发快吗？

全map 全string DBhelper的系统设计方式 以前我们也用过
我们公司系统最初的框架就是这么做的
那时候我还没来公司
但现在公司换了 我想换有换的理由
我们公司实际上新手很多 开发时间很紧 如果这种方式有效的话 没理由换吧

我最早独自管理一个项目，也是一个日本的外包，也是日本鬼子要求我们用j2ee。我一个人既当爹又当妈，既要管人，订计划，又要写框架。然后就搞出一个类似lz这样的东西，到处是map和sql。后来就是升级，对应，修改bug，变更不断。那段时间铺了个睡袋天天睡在公司，每天上午写email，下午看式样书，晚上把伙计们留下来开个会，夜深人静的时候check out最新的代码检查一下。后来我离开这个项目，公司里仍然有人在这个框架上继续开发着，经常加班到天明。
我现在怀疑鬼子是不是要破坏中国的软件业，故意设计了很多烟囱式的系统，拿到中国来开发，向一代代的程序员灌输错误的开发思想。

显然，这个框架是挂羊头卖狗肉，挂的是OO的羊头卖的是过程开发的狗肉。
业务需求一变化，累死你

这不能算是什么框架，框架的最根本作用就是对未来业务需求的变化能快速对应，对原来系统进行扩展。
如果有业务改动，改动很累的