colstr = colstr.substring(1);
valstr = valstr.substring(1);
}
sqlstr = "INSERT INTO "+c_table+" ("+colstr+") VALUES ("+valstr+")";
return sqlstr;
}else if(c_genre.equalsIgnoreCase("UPDATE")){
java.util.Enumeration arg_names = request.getParameterNames();
String colstr = "";
String arg_name,pre_name,end_name ;
while(arg_names.hasMoreElements()){
arg_name = String.valueOf(arg_names.nextElement()).trim();
if(arg_name.length() < 2){
continue;
}
pre_name = arg_name.substring(0,2);
end_name = arg_name.substring(2);
if(pre_name.equalsIgnoreCase("i_")){
if(get(arg_name).equals("")){
colstr += ","+end_name+"=NULL";
}else{
colstr += ","+end_name+"="+get(arg_name);
}
}else if(pre_name.equalsIgnoreCase("s_")){
if(get(arg_name).equals("")){
colstr += ","+end_name+"="+get(arg_name);
}else{
colstr += ","+end_name+"="+get(arg_name).replaceAll("","")+"";
}
}
}
if(!colstr.equals("")){
}
sqlstr = "UPDATE "+c_table+" SET "+colstr;
if(!c_where.equals("")){
sqlstr += " WHERE "+c_where;
}
return sqlstr;
}else if(c_genre.equalsIgnoreCase("DELETE")){
sqlstr = "DELETE FROM "+c_table;
if(c_where != null && !c_where.equals("")){
sqlstr += " WHERE "+c_where;
}
}else{
com.river.debug.Debug.show("unknow action type : "+c_genre);
return null;
}
return sqlstr;
}
public String toString(){
return "version 1.0, date 2005.03.02, author river";
}
}
这样我们就可以根据页面元素的命名来指导SQL语句的生成。这样做有很多的明显的好处：
1. 减少编码工作，对于元素很多表单，用不着我们去写一大堆的代码，不用去担心哪个元素落下了，元素名有没有些错，单引号有没有处理。
2. 通用、稳定、易于维护，javabean固有的优点，就不用太多的说明了。
3. 分离表层的表单内容与逻辑层SQL语句的构造。设想一下，如果我们数据库表结构有调整时，那么我们只要修改一下表单就好了，根本就不用理原来写好的逻辑处理。附带着再说一句，设想如果我们再写一个类自动执行SQL，那么对于一些基本的增、删、改操作都可以映射到同一个action里面来处理，且不是很爽？
当然，这样做的缺点也是有的。那就是有一定的性能损耗。特别是碰到表单元素非常多时。但是我想对于那些不是很"苛刻"的项目这点损耗是值得的。