前面提出了关于SSH架构中struts的鸡肋问题,大家也给出了热情洋溢的意见,表达了各自的观点:
原帖链接: http://www.iteye.com/post/1027849?page=1
大家对于实战中存在的这样一种现状还是有共识的,确实存在开发效率的问题。如何解决?右派认为忍气吞声吧,不就是多写点代码而已,没什么大不了;左派很激烈nostruts吧struts2吧.....当然还有理性的声音,改革吧....
当然说struts鸡肋也有点夸张只是为了让大家兴奋起来才如此称呼而已。客观的讲struts本身的架构设计是符合<J2EE核心模式>的,作为展现层的基础架构,struts很好的完成了自己的使命,在j2ee混沌刚开劈疆拓土的时代这面大旗的咧咧风声功勋卓著。
--------------------------
言归正传:
我的意见是:既然他们贫血,而且应该贫血,那么就让他们彻底贫血彻底消失,起码在某些场景下消失,省得这样的代码影响市容影响和谐,提高各位键盘的寿命。
做法就是对这些贫血对象作封装,不要在开发中频繁写这样的对象,而且封装其实很简单的。同时封装时只针对我们说的简单场景,不阉割struts功能,对于复杂点的例如依赖servlet接口的一些操作依然可以按照传统的action处理。
--------------------------
- Nice Struts 效果,Struts配置:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://struts.apache.org/dtds/struts-config_1_2.dtd"> <struts-config> <form-beans> <form-bean name="niceForm" type="com.*****.nstruts.NiceForm" /> </form-beans> <action-mappings> <action path="/addBook" parameter="bookManage.addBook(book)"----------------- 1 scope="request" type="com.****.nstruts.NiceAction"---------------------------------------------- ------ 2 name="niceForm">--------------------------------------------------------------- -------3 <forward name="success" path="/getAllBooks.do"></forward> <forward name="fail" path="/***.jsp"></forward> </action> <action path="/delBook" parameter="bookManage.delBook(bookid)" scope="request" type="com.****.nstruts.NiceAction" name="niceForm"> <forward name="success" path="/getAllBooks.do"></forward> </action> <action path="/modifyBook" parameter="bookManage.modifyBook(book,oldId)" scope="request" type="com.***.nstruts.NiceAction" name="niceForm"> <forward name="fail" path="/book_modify.jsp"></forward> <forward name="success" path="/infoBook.do"></forward> </action> <action path="/getAllBooks" parameter="bookManage.getAllBooks():books" scope="request" type="com.***.nstruts.NiceAction" name="niceForm"> <forward name="success" path="/book_all.jsp"></forward> </action> </action-mappings> </struts-config>
不同指出就是上面的1/2/3:
首先通过parameter指明需要执行的业务层方法,可以是多个业务方法;
其次指定使用基础的NiceForm(开发时不需要自己实现)
最后是指定基础的NiceAction(开发时不需要自己实现)
(需要说明的是在这个配置文件里完全可以混用传统的自定义的action/form)
2。Nstruts效果之jsp页面
<html:form action="addBook.do" method="post">
<br>
<table border=0 cellpadding=1 cellspacing=1 class="query_table"
style="width: 60%" align="center">
<tr>
<th colspan="10">
<div align='left'>
<b>图书登记</b>
</div>
</th>
</tr>
<tr>
<th>
书名
</th>
<td>
<html:text property="$(book.name)" size="70"/>
</td>
</tr>
<tr>
<th>
出版社
</th>
<td>
<html:text property="$(book.publisher)" size="70"/>
</td>
</tr>
<tr>
<th>
作者
</th>
<td>
<html:text property="$(book.author)" size="70"/>
</td>
</tr>
<tr>
<th>
单价(分)
</th>
<td>
<html:text property="$(book.price)" size="70"/>
</td>
</tr>
<tr>
<th>
备注
</th>
<td>
<html:textarea property="$(book.memo)"/>
</td>
</tr>
<tr>
<th>
发行日期
</th>
<td>
<html:text property="$(book.born)" size="70" value="2008-04-23"/>
</td>
</tr>
</table>
<table width="60%" align="center">
<tr>
<td align="center">
<br>
<input type="button" class="btn4" value="提 交" οnclick="subform()">
<input type="button" class="btn4" value="返 回" οnclick="goBack();">
</td>
</tr>
</table>
<br>
</html:form>
唯一的不同在于属性引用需要$()一下,因为目前使用的MapForm的形式扩展actionform了,高手一定会想到NiceForm中一定定义了一个get$()/set$(),呵呵。这个$其实可以省略,方法就是上帖中大家提到的lazyValidateForm。
3.service层一如既往,目前的限制是特殊的多态方法支持有问题。明眼人一看就知,反射了嘛,呵呵。。。。
END--------------------------
这样以来大家看,Struts在SSH中的角色依然,作数据的提取/展现/页面流的配置。同时没有了所说的两个鸡肋问题,struts的结构没有打乱功能没有阉割,符合一贯的开发习惯,而且足够灵活,呵呵,有点自买自夸的嫌疑。
总之罗嗦了这么多并非仅针对struts,而是为了抛砖引玉,为了说明一种技术领域的现象和个人的体会,j2ee领域的基础组件之所以灵活甚至累赘就是为了给上层的应用架构提供扩展点,struts并非鸡肋,鸡肋是我们自己的问题。在应用架构中对基础的j2ee组件/架构进行一定的扩展定制是必要的,是架构师的职责所在,只会将S/S/H一会NBCD等等堆砌在一起抑或动辄就高喊struts2吧,这样的架构师尚需要努力。
期望与各位分享在开发面向最终应用的技术框架过程中的一些创新和灵感。
Over!!!!