Struts2的前景还是稳健的,使用的人数在不断的增加。参加struts 2依然坚挺 Seam前景不明
但基于Struts2的开发,如果没有足够的经验和规范做支撑,并不能带来还多的好处,如果失控,一样和JSP+servlet泛滥,这一点需要警示。
1).Action类及Action Name的命名规范
Action类的后缀统一加上"Action",Action的Name与类的名称保持一致,但不要"Action"的后缀。
这样是为了通过Action的调用url, 很方便的找到Action类。
1 < action name ="searchKnowledge"
2 class ="com.demo.search.action.SearchKnowledgeAction" >
3 < result name ="search" > /demo/search.jsp result >
4 action >
如上,看到/searchKnowledge.action,就可以很清楚的知道类是SearchKnowledgeAction了。很多人不注重这一点,开发调试中,每次都要笨拙的看struts.xml文件。
2).每个项目都必须至少有一个公用的Action类,GenericAction完成的功能如下:
1.获取、注入request
2.获取、注入Session
3.错误页面跳转
4.获取在线用户和会员的信息(个人信息、权限、角色等)
5.注入类型转换的格式转换类,如日期类型转换:ConvertUtils.register(new DateConverter(), Date.class);
6.获取系统配置信息,如公用变量(如配置路径等)
7.对于request参数的处理等8.其他可扩展的操作
3).擅长使用Dispatch的模式
有人说Action,不就是Dispatch的延伸吗,其实还可以做的更好。
这个典型的模式如下:
1.页面表单的Hidden参数中,就是一个ID,如queryID="queryKnowledges". Action="/paginate.action"
2.PaginateAction的模板如下
1 private String queryID;
2 public String execute() {
3 //获得Service的接口
4 //根据queryID调用Ibatis分页查询方法
5 return queryID; //这一点,就是动态跳转,在Action不明确注明"success"之类的跳转名称。
6 }
3.在struts.xml中进行配置与queryID想对应:
1 < action name ="paginate"
2 class ="com.gehc.util.pagination.PaginateAction" >
3 < result name ="queryKnowledges" >
4 /demo/knowledgeList.jsp
5 result >
6
7 < result name ="queryIssue" >
8 /pm/issue/allIssue.jsp
9 result >
10
11 action >
实战代码如下:
4).配置文件的目录结构
5).不断的提炼公用的Action,并放在一个package中:如上传、下载、异常处理、excel数据录入、过滤器(filter)、截取器(inteceptor)等等
6).将一个模块中的Action放置在一起
7).擅与使用redirect来保持request参数。
使用redirect一样可以将request参数传递到下一页面中,不需要使用session.
viewPost?postid=${postid}
public String execute() throws Exception {
// 一些处理……
name = xiaowang ; // 给要传递的参数赋值
return SUCCESS; // 默认页面
// return "redirect_1" ; // 重定向(不带参数) showInfo.do
// return "redirect_2" ; // 重定向(带固定参数yangzi) showInfo.do?name=yangzi
// 重定向(带动态参数,根据struts.xml的配置将${name}赋值为xiaowang)最后为 showInfo.do?name=xiaowang
// return "redirect_3" ;
// return "redirect_4" ; // 这个是重定向到 一个action
}
8)明确Action类不要超长,如不要超过500行代码。
很多人为了偷懒,喜欢在一个Action中,不断的添加方法,而不管这些方法与Action的语义是否符合,到底是多个Action,还是多个方法,在开发过程中,还是要注重这些方法是否与创建Action类的目的、语义保持一致。
最好明确代码的长度,团队人多,手杂,水平不一,为了保证可维护性,这是一个不得已的方法。
本文作者:佚名 来源:本站原创
CIO之家 www.ciozj.com 微信公众号:imciow