Nice Struts～鸡肋问题解决之道

前面提出了关于SSH架构中struts的鸡肋问题，大家也给出了热情洋溢的意见，表达了各自的观点：

 

原帖链接： http://www.iteye.com/post/1027849?page=1

 

大家对于实战中存在的这样一种现状还是有共识的，确实存在开发效率的问题。如何解决？右派认为忍气吞声吧，不就是多写点代码而已，没什么大不了；左派很激烈nostruts吧struts2吧.....当然还有理性的声音，改革吧....

 

当然说struts鸡肋也有点夸张只是为了让大家兴奋起来才如此称呼而已。客观的讲struts本身的架构设计是符合<J2EE核心模式>的，作为展现层的基础架构，struts很好的完成了自己的使命，在j2ee混沌刚开劈疆拓土的时代这面大旗的咧咧风声功勋卓著。

－－－－－－－－－－－－－－－－－－－－－－－－－－

言归正传：

 

我的意见是：既然他们贫血，而且应该贫血，那么就让他们彻底贫血彻底消失，起码在某些场景下消失，省得这样的代码影响市容影响和谐，提高各位键盘的寿命。

做法就是对这些贫血对象作封装，不要在开发中频繁写这样的对象，而且封装其实很简单的。同时封装时只针对我们说的简单场景，不阉割struts功能，对于复杂点的例如依赖servlet接口的一些操作依然可以按照传统的action处理。

－－－－－－－－－－－－－－－－－－－－－－－－－－

1. 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="提  交" onclick="subform()">

                &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

                <input type="button" class="btn4" value="返  回" onclick="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!!!!

 

 

说句题外话，因为我们公司用的是SpringMVC，前端页面逻辑用的是通用配置，平时要增加一个前端控制类几乎不用写任何配置文件，最近一直没时间转向Struts2（还是喜欢Struts2的action的状态属性线程安全，能更方便的封装一些工具方法）。

但我总觉得，Struts2也可以多采用一些约定大于配置的技巧，使得增加一个action不需要写这么多行配置。主要原因是，配置文件中80%的内容是不需要单独配置的（也就是说对于这80%不可能出现只改配置文件而不改代码的情况发生，此时配置文件可以认为等同于代码，这部分的逻辑直接写进代码，而不写在配置文件中）。

据说SpringSide3做到了零配置，我不是说一定要零配置，而是建议借鉴一下约定大于配置的思想，没那么多可能要修改的地方需要配置文件，真的要修改了，直接改代码好了，本来层次划分清楚，action中的代码已经很精简了，页面逻辑就从配置文件转移到action中不是蛮好的么？

to:icewubin

同感，在上层的应用架构中适当引入契约可以提高开发效率，但是不能以契约模式作架构基础。

to:
action中的代码已经很精简了，页面逻辑就从配置文件转移到action中不是蛮好的么？

换句话：页面逻辑就从action转移到配置文件中不是蛮好的么？上面的nstruts做得就是这个，关键问题是不要既有配置文件，还有贫血的action.

不完全是契约模式，而是更注重页面逻辑转移到action中。

IDE对Java的支持要远好于IDE对XML的配置，对于那部分几乎不存在的“幻影需求”（部署的时候现场只改配置文件，不修改代码），完全可以不做理会。

再多说一句，上述的“幻影需求”完全是发版、修改和维护的话题，有的是办法解决，没必要通过成本如此高的配置文件（Struts2的低效配置方式）来解决。

那种配置文件万一错个字母你要找好半天

蹩脚低效的配置文件确实令人深恶痛绝

楼主请允许我说句实话，我觉得这是条歪路

楼上能否解答一下何谓歪路啊，歪于不歪档看是否能解决问题而论吧。楼上是否认为文中所提的问题不是问题，抑或有更好的解决办法？？期待指教。

用SpringMVC的很少啊。
呵呵，有JROR嘛？比较支持这个。

要考虑新人的学习成本和学习积极性，Struts2的资料还是很多的，新人们也认为这玩意儿学了不愁找不到工作。

还有就是做方案的时候，评审方案的人都认识Struts2，其他的框架有些人就不认识。