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!!!!

 

 

评论

33 楼 jieyuan_cg 2009-05-31  

呵呵，公司用ofbiz，一样解决上述问题。
传值用Map封装，控制逻辑用control.xml配置文件来解决。

32 楼 icewubin 2009-05-31  

betafox 写道

pipilu 写道

真要零配置，那就从命名上给规范了，使用反射来动态加载（根据一定的名称规则和包结构）。
使用注解那哪叫零配置？？

使用注解只是配置转移了，呵呵，把矛盾转嫁了，如果不分场景的使用注解，可预见的未来会有针对注解的另一场口诛笔伐。个人认为技术都是又实用场景的....

我不是想引起这个讨论，因为很早以前就讨论了不知道多少次了。再说一次好了，配置文件分两种，一种是一直以来就有的例如“数据库连接属性”、“Log4j”的配置文件，而另一大类就是Struts2的页面转向逻辑和Hibernate的映射配置文件，后一大类情况还不一样，Struts2的页面转向逻辑基本属于“幻影需求”，而Hibernate的映射文件更多的是出于无奈，后来采用注解并兼容JPA规范后就很好用了，对与这一类的配置文件我不认为是真正的“配置文件”，用途不同而已。

所谓的“幻影需求”再重复一下，期望在需求变化时，系统不修改代码，而仅仅修改配置文件就能够轻松搞定，可能么？实际多做几个项目就知道了，这种幻影需求的可笑了。

这方面仅仅表述struts2的默认的配置文件过于重载而已，xml配置文件本身也是可以做出改变的，Spring的配置文件就是不断在演进的。

31 楼 betafox 2009-05-31  

pipilu 写道

真要零配置，那就从命名上给规范了，使用反射来动态加载（根据一定的名称规则和包结构）。
使用注解那哪叫零配置？？

使用注解只是配置转移了，呵呵，把矛盾转嫁了，如果不分场景的使用注解，可预见的未来会有针对注解的另一场口诛笔伐。个人认为技术都是又实用场景的....

30 楼 icewubin 2009-05-31  

pipilu 写道

真要零配置，那就从命名上给规范了，使用反射来动态加载（根据一定的名称规则和包结构）。
使用注解那哪叫零配置？？

一般说的零配置就是指零XML配置文件。

注解当然是另一种配置方式，但是IDE对注解的支持远好于XML配置文件，注解本身是强类型，具有编译期检查、继承等特性，重构支持也非常好，大多数情况下配置效率也比XML方式高。

29 楼 pipilu 2009-05-31  

真要零配置，那就从命名上给规范了，使用反射来动态加载（根据一定的名称规则和包结构）。
使用注解那哪叫零配置？？

28 楼 xzj127 2009-05-30  

还是喜欢 Spring 的 MVC 。。

27 楼 betafox 2009-05-29  

aws 写道

零配置个人感觉没啥意义或者说是倒退
配置文件的出现本身上为了保持代码不变的情况下将设置集中管理，注解式配置实际上上走回分散设置的老路，简直类似于JSP中不写<% %>之后有人觉得用起来不够爽又重新拿出<% %>

以ssh的架构，dao+(biz+service)+action+view这样的结构，struts的action层完全可以虚化掉，页面转向控制交给配置文件，业务逻辑集中到service层，用一个base action类来充当中央控制引擎，根据IOC的配置调用与组装service内的业务逻辑，对数据的校验，等等，用自定的map取代request，一方面简化掉了action，另一方面也可以通过替换base action来达到不同的效果，比如输出的数据格式，可以无缝的把struts的form变成json数据，或者xml数据，或者其他什么

听起来是不是有些部分像webwork

不谋而合，这种思路适合很大一部分需求，屏蔽了诸多技术细节，拯救将劳苦大众与技术纠缠的水深火热，对于大规模快速应用层开发大有裨益。楼上一席话总结了一开始例子中对struts的封装思路，赞一个！！！

至于零配置我倒是觉得并非全无意义，零配置针对的是目下java领域配置泛滥的弊端，还是那句话：要配置还是要0配置需要根据具体的应用场景，要因地制宜”识别配置的必要性“，相互结合取长补短，灵活机动的选择。

26 楼 icewubin 2009-05-29  

aws 写道

听起来是不是有些部分像webwork

Struts2就是webwork2。

25 楼 aws 2009-05-29  

零配置个人感觉没啥意义或者说是倒退
配置文件的出现本身上为了保持代码不变的情况下将设置集中管理，注解式配置实际上上走回分散设置的老路，简直类似于JSP中不写<% %>之后有人觉得用起来不够爽又重新拿出<% %>

以ssh的架构，dao+(biz+service)+action+view这样的结构，struts的action层完全可以虚化掉，页面转向控制交给配置文件，业务逻辑集中到service层，用一个base action类来充当中央控制引擎，根据IOC的配置调用与组装service内的业务逻辑，对数据的校验，等等，用自定的map取代request，一方面简化掉了action，另一方面也可以通过替换base action来达到不同的效果，比如输出的数据格式，可以无缝的把struts的form变成json数据，或者xml数据，或者其他什么

听起来是不是有些部分像webwork

24 楼 betafox 2009-05-29  

呵呵，o配置，也仅仅是另一场忽悠的风波罢了吧，注解+配置+根据场景选择....唉

23 楼 holan 2009-05-29  

spring mvc很劲爆，加上注解，差不多0配置了

22 楼 betafox 2009-05-28  

楼上所谈的确实是我们选择技术架构时必须考虑的问题，相信对大家都有启发性的意义，感觉咱们的讨论太发散了，呵呵。如有必要建议另立贴与大家展开讨论这方面的话题，否则java阿姨的管理员要说这个贴没有主题、不知所云、太发散、可能要被评隐藏贴了，呵呵，觉得java阿姨太严厉了点！！

21 楼 icewubin 2009-05-28  

还有就是IDE的问题，如果IDE对XML的生成和重构能够达到Java的程度，也不会有那么多人抱怨重载的XML配置文件了。

如果IDE没有良好支持get和set代码的生成，一样会有很多人骂娘直到质疑标准JavaBean规范的低开发效率。

华山论剑总是要有规则的，除非楼主你事先定好前提，例如：只讨论开发效率，不考虑其他相关成本。这样就可以了。

20 楼 icewubin 2009-05-28  

还有就是历史遗留问题，刚才有网友说了利用注解解决零配置的问题，在我们公司暂时不可能采用的。

因为客户那里有不少环境就是不支持JDK1.5的，我们也没有办法。

19 楼 icewubin 2009-05-28  

betafox 写道

to:楼上
-------------
我这里说的评审不是公司里的人，往往是客户那里的人，我们作为乙方如何去评判客户是否有资格做评审。
客户那里总有些自以为是的IT部的人，这是没办法的事。
----------------------------------------------------------
我们只讨论技术层面的问题，你提的这些问题提当然确实存在，但是我们是无能为力的，所以不要把这种因素纳入我们的话题，那样就大了，呵呵，华山论剑只谈剑术。

这个不可能的，就好比单考虑技术层面普元EOS的东西没什么特别不好的地方，但是公司里就是绝大部分的人不愿意做EOS相关的东西，想留住人必须高薪，这个成本必须要考虑的。再或者我认为JavaFX技术体系也不错嘛，但是想想这东西能成功么？（历史上优秀的技术最终没有成功的多了去了）

一个技术相关的成本有很多，学习成本之类的难道不考虑么？

回过头来说，客户也不会很无理的说，“我没听说过，不能用这个方案”，例如我们现在用的SpringMVC也算是不太普及的MVC框架，客户知道我们一直在用这个框架，所以不会有太多意见，有分歧早就沟通过了。但是如果我们公司突然要换框架，他们当然有询问为什么要换，理由风险等等等。

假设我说要换“Tapestry”，好，你想想他们会怎么做，首先就是google，然后旁敲侧击的问同行等各种手段来了解，而国内Tapestry的好评和成功案例并不是太多，无形中增加我们乙方的成本。

还有，比如现在有一个系统，不考虑甲方、不考虑技术学习成本、不考虑维护成本、不考虑交接成本，需要招人，马上就要开工，而这个系统既可以用存储过程、也可以J2EE（Struts2）、也可以ROR，光是一个招人成本就决定了，我一定是招J2EE（Struts2）的。

当然有了这么多假设好像没有意义，有点先有鸡还是先有蛋的问题，那就回头来说为什么国内招Struts2的好招又便宜呢？表面上看是因为很多培训学校教这个，很多公司确实也是用这个。再深究为什么会产生“表面上看到”的原因呢？间接证明Struts2确实是一个优秀的框架（即使曾经是），能够（相对的）提高生产效率、减少维护成本等，所以慢慢在国内普及（当然还有Struts1大大的功劳）。

18 楼 betafox 2009-05-28  

to:楼上
-------------
我这里说的评审不是公司里的人，往往是客户那里的人，我们作为乙方如何去评判客户是否有资格做评审。
客户那里总有些自以为是的IT部的人，这是没办法的事。
----------------------------------------------------------
我们只讨论技术层面的问题，你提的这些问题提当然确实存在，但是我们是无能为力的，所以不要把这种因素纳入我们的话题，那样就大了，呵呵，华山论剑只谈剑术。

17 楼 icewubin 2009-05-28  

黑暗浪子 写道

icewubin 写道

黑暗浪子 写道

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

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

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

个人觉得如果评审的人只知道struts2，其他不是很明了的话，那是没资格做评审的。
连各个框架优缺点都不清楚，怎么能去评审？
还有seam，不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。

我这里说的评审不是公司里的人（在我们公司这部分是我说了算的），往往是客户那里的人，我们作为乙方如何去评判甲方是否有资格做评审。

客户那里总有些自以为是的IT部（或者信息公司）的人，这是没办法的事。

至于Seam么，只要他们公司有个大牛能够搞定相关的一些攻坚问题，订好规范，没什么问题，完全可以采用。

16 楼 betafox 2009-05-28  

黑暗浪子 写道

个人觉得如果评审的人只知道struts2，其他不是很明了的话，那是没资格做评审的。
连各个框架优缺点都不清楚，怎么能去评审？
还有seam，不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。

严重关切严重同意

15 楼 黑暗浪子 2009-05-28  

icewubin 写道

黑暗浪子 写道

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

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

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

个人觉得如果评审的人只知道struts2，其他不是很明了的话，那是没资格做评审的。
连各个框架优缺点都不清楚，怎么能去评审？
还有seam，不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。

14 楼 icewubin 2009-05-28  

kjj 写道

struts2 已经有一个插件支持类似rest的风格，不需要再在xml里一个个配置action了，可以说约定》配置的插件！你对这个还不满意！

啊？没有不满意，我就是建议楼主这么做啊。我是想引出后续的话，这些零配置的东西其实是变相的“配”在action中，所以action这一层并不是鸡肋。