改进架构，实现动态数据源，结束java开发生活

呵呵，这位仁兄想法还好吧，难道你想把业务逻辑全部放在JavaScript里？维护起来也是也是一个恶梦。。。。

对耶，我也感觉很可怕，总不能让js做业务吧，这太难维护了，万一出个什么问题，真不敢想了。

用dbform貌似连前台都不用写了

前台和后台耦合太高 比如说前台居然要记住文件系统xml文件的名字 这个不太好

这个不是要解决所有方面的所有问题，对于前端经常变换的业务还是比较有效的。写操作当然还是传统方式，这里面只处理读操作，而且是公开的读操作。

对于“drop table”，要明确sql是你先配置的，不是用户传入的，不可能执行任意sql，对于注入，都是PreparedStatement方式设置传入的参数，怎么会有SQL注入哪。最差情况下，打开的数据库连接也是只读的，不可能去更改任何数据。

1 似乎只适用于报表显示，只读？
如果是这样的话，那么流行的做法是sql返回xml形式的结果集，配合xstl转成html。
2 不仅只读？那么逻辑写在js里？显然不安全，也不合适。

其实业务逻辑是无法被消灭的，你能做的或许是把逻辑从后台java移到前台js。从而达到js和db‘直接’（通过commonservlet）交互，这是一种2层架构。从安全性考虑，sql语句不保存在js。但这样安全性还是不够的。

数据库事务怎么处理？

只适用于select

目标1：降低项目维护成本。维护上大部分的变化还是页面，主要就是select；如果设计业务逻辑调整，事务之类的，一般就是大变化了。

目标2：产品落地定制。产品实施很多时候也是页面调整，大部分还是select。

其实select已经能够解决很多问题了。这种设计也不是为了解决所有问题，要不就是asgard的技术啦。。。。

简单业务应该能顶住
复杂的业务估计不行 的复杂业务一般有非常多的对中间状态的if else 逻辑。中间层还是必不可少的