这两天在看jdon框架里面的例子，还没深入去研究，有几点疑惑还请bang大哥和道兄解惑：
1.我一直不大愿意用actionform，更不愿意把表单验证和逻辑验证放到服务器端，但是我看到jdon例子里都是这样的，我想知道这样做有什么具体的优点；相比在客户端来验证，其开发和维护是快了还是慢了？
2.对于多表查询和页面里的动态表单（如：动态增加和删除表格）是不是比传统的开发还要复杂？
3.如果模块多了，相应的代码文件和配置文件也会级数增加，这给开发和维护是不是也带了很大的麻烦；
目前只认识了这么多，敬请解惑！！再线等待。
lz说的没错，我现在也在研究Jdon框架，lz提到的问题在我新的项目（作为学习用）中也暴露出来，对于表单校验我倒是采用了传统的javascript来做。
另外对于多表查询等一些方法，我只有自己再写方法通过struts来实现。比如往数据库中存放Clob对象时，我就只有自己在写相应的方法。
项目的进展不是很大，可能不是很熟悉的缘故。
》更不愿意把表单验证和逻辑验证放到服务器端
服务器端验证安全高，因为html客户端用户可以避开JS做一个新的表单来提交，客户端验证则用户感受好，另外Struts也提供客户端JS验证的表单，这样前后台一起做，开发速度会提高的。
对于我个人而言，我宁可多做服务器端，而不愿做JS，因为JS调试时间是Java调试的好几倍，维护成本很高，JS只做一些通用的功能验证。
>2.对于多表查询和页面里的动态表单（如：动态增加和删除表格）是不是比传统的开发还要复杂？
多表查询关键做好是ActionForm组件设计，以及JSP页面的标签库应用，当然页面组件不可能是一个可能是多个，这里面其实体现了Model设计技巧，因为ActionForm只是Model的一个复制和影子，在JSF等中可以直接使用Model作为页面组件，但是个人感觉留一个专门页面组件比较灵活，可以做一些适合界面但不涉及业务模型的变化。
动态表单关键也是页面组件设计，以及JS的使用，有一个BSF框架使用Struts可以将页面表单做得非常灵活，可以参考一下。
>模块多了，相应的代码文件和配置文件也会级数增加
模块多了，实际就是组件块多了，每个组件块有自己一套代码和配置，就象小公司没有组织之分，但是大公司人多了，就部门之分，只要做到清晰的组件规划，反而更有条理，每个组件块都有其核心业务Model，就象每个部门都有经理一样，虽然部门多，只要抓经理就可以，虽然组件块多，只要抓Domain Model就可以。
对于jacal提出的多表查询，在JF中批量查询功能，好像只是针对单表查询，其实，这是误解，这里的单表其实是一个业务Model，为什么我们有时会有多个表，因为我们使用的是面向数据表的设计方法，而不是使用面向Model设计方法。
一个业务Model必然会和其他Model发生类关系，如果是一对一，我们直接在Model类中引用另外Model就可以，如果是一对多，我们使用Collection，当然，这里涉及到双向还是单向，具体选择可以看页面的多表查询要求。
如果我们把多表查询理解为多Model查询的话，那么这多个Model中必然有一个主Model，其他次要Model只要通过主Model的单向或双向类关系实现引用就可以，这样，在Jsp页面通过标签库login:iterator遍历时，每一个遍历是一个主Model，再通过类关系将其他次要Model显示出来，所以Struts的嵌入标签作用很大，如下：
|
上面就是输出主Model为aaa的一对一关系的对象bbb的属性name值。