我打算用一个filter[ServiceGateway]做/service/*的拦截，避免对/service/中各模块的直接访问，然后此filter的init方法里读取一个properties文件中的配置数据，简单举例如：
v[1]=true,
s[1]=CRUD,
c[1]=SELECT id,title,datetime FROM news WHERE classid=? ORDER BY id DESC LIMIT ?,?|classid.i.1.1.5,m.i.0.0.0,n.i.1.1.0
这样前台调用
/service/?o=1&classid=5&m=20&n=10
就相当于要先根据v[1]作验证，v[1]=true所以要检查权限，检查通过后将参数
request.setAttribute("serviceConfig",c[1])
最后
RequestDispatcher requestDispather=request.getRequestDispatcher("/service/"+s[1]);
requestDispather.forward(request,response);
送到CRUD模块（一个Servlet或jsp）继续操作，这时CRUD根据配置
classid.i.1.1.5,m.i.0.0.x,n.i.1.1.x
读取p[1]=int classid，默认1，最小1，最大5；p[2]=int m，默认0，最小0,最大不限；p[3]=int n...插入
SELECT id,title,datetime FROM news WHERE classid=? ORDER BY id DESC LIMIT ?,?
执行并返回文本数据。
这样就可以通过修改properties文件实现不同简单的数据库操作。
而其他模块如登陆验证、文件上传等需要的参数就更少更简单了。
可以通过附加另外一个filter在Service模块执行前检查是否存在o=1&classid=2&m=20&n=10.js文件，如果有直接返回该文件，如果没有就执行Service模块CRUD，并获取其返回码，生成并返回该文件以实现Cache。这种js文件中都是元数据，与生成.html相比占用空间小，读取快。
不知道这种做法科学吗？是否算是Mediator的一种？
其实我最关心的问题是，究竟是只用一个Servlet作为controller，在其中动态加载Service Model class的开销大，还是每个Service Model做成一个Servlet然后用这个ServiceGateway做过滤的开销大呢？
因为每个Service Mode都必须返回一个字符串，前台使用ajax读取，所以并不存在jsp文件，也就少了很多servlet，如果采用一个Servlet作为Controller并动态加载其他类，那整个系统似乎只要有一个Servlet就够了。
附：这几天用上边的想法做了几个简单的功能，仅包括CRUD模块和Parameter的自动读取，测试结果还算满意，和以前用Bean封装并传递数据的比较如下：
旧方法：30条/页，第1页=53ms，第700页=100 ms。
新方法：30条/页，第1页=40ms，第700页=73 ms。-取到数据后装入StringBuilder然后统一out.write
新方法：30条/页，第1页=40ms，第700页=73 ms。-直接out.write
注：
·旧方法用的是statment，新方法用的是prepareStatment。
·旧方法=Mode1，jsp+javabean的方法。用getXXX和setXXX操作数据并放在ArrayList里。
·操作时间本来还有个DB消耗时间，但多数时候DB的消耗时间和页面的消耗时间是一样的，就没列出来。（因为在get connection之前和close之后的操作很少）
·但新方法1在输出大量字符的时候，比新方法2表现略好，平均要快5ms。
时间关系，所作测试有限，可以肯定这种办法要简单直接快速一些，因为对元数据没有封装。对这些元数据的处理将直接交给前台的javascript。
前台方面目前写好了
sendRequestAndGetResponse.js和putDataInTemplate.js
但是还有些地方需要完善，所以代码暂时就不发上来了。
待确定这条路是可行的，再花更多的时间去完善他，并拿出来与大家交流。