SSH架构中的Struts似乎很鸡肋

在基于SSH的架构中，基本的流程是这样的：

 

1、展现层通过struts收集数据

2、在action中调用服务层业务接口，实现业务逻辑处理

 

（这里说的是struts1）

 

在这样的过程中始终存在如下很鸡肋的问题：

-------------------------------------------------------------

 

1、struts action变得很贫血。

 

     由于业务逻辑后置，用了action没有带来实实在在的好处，反而增加了交互的环节。典型的action使用mapping dispatch模式，每个action方法只有3行代码 ：

 

 

    /**
     * 获得权限树,转向权限树页面
     */
    public ActionForward getFunctionTree(ActionMapping mapping, ActionForm form,
                                         HttpServletRequest request, HttpServletResponse response) throws StaffException {
        Collection tree = helper.getFunctionRootTree();
        request.setAttribute("tree", tree);
        return mapping.findForward("tree");
    }

 

    public ActionForward getRoles(ActionMapping mapping, ActionForm form,
                                  HttpServletRequest request, HttpServletResponse response)
            throws StaffException {

        Collection roles = helper.getAllRoles();
        request.setAttribute("roles", roles);
        return (mapping.findForward("success"));
    }

 

 

 

2、struts actionform也贫血，而且粒度很难把握

 

    由于form中的属性往往和业务层的Model对象存在相似性，所以在form中定义model的引用是常见的办法：

 

import com.surekam.platform.staff.model.Department;
import org.apache.struts.action.ActionForm;

public class DeptForm extends ActionForm {

    /**
     * 部门信息
     */
    private Department department = new Department();

    public Department getDepartment() {
        return department;
    }

    public void setDepartment(Department department) {
        this.department = department;
    }

}

 

如果这么做，form的价值在那里？？ 唯一的必要性可能就是struts的表单标签要求必须有form，这不是很鸡肋吗？

 

另外实战中为了节省form的数量，往往会在多个操作中共享form类，结果是造成了form完全成了大杂烩，完全不可读！！

 

 

--------------------------------------------------------

 

 

那么从架构的角度来看，这很明显是一个共性的问题。望各位仁者见仁，将大家在实战中的经验共享一下，一起探讨解决方案。

 

我们的解决办法是对struts进行了一定得封装和扩展，有一个所谓的Nice Struts的组件来搞定这个问题。稍后会提供具体实现出来。

ENDING----------------------------------------------------------------------------------------------------------------------------------

 

帖子大家回了很多了，关于鸡肋的问题我想大家讨论就到此为止吧，呵呵！

 

本帖的目的是为了引起大家重视这个问题，即：对开源组件及其套装在实战中与我们所期望的“应用层架构”之间的不协调，并在架构实践中多加思考，只是用struts做个例子而非针对struts而来。

 

 

事实：鸡肋的其实不是struts，我们自己要检讨！

 

参见下一帖 鸡肋问题解决之道！欢迎大家接着仍鸡蛋！<iframe></iframe>

 

http://www.iteye.com/topic/396024

评论

63 楼 apple.shan 2009-09-11  

wxq594808632 写道

betafox 写道

to:wxq594808632

辛苦了阿，看来也是对form深恶痛绝了阿！

本来是测试je文件上传的.忘记删除了.

ps:好像只有文件上传用下form

文件上传为什么一定要用form？？可以不用

62 楼 wxq594808632 2009-06-16  

betafox 写道

to:wxq594808632

辛苦了阿，看来也是对form深恶痛绝了阿！

本来是测试je文件上传的.忘记删除了.

ps:好像只有文件上传用下form

61 楼 supercrsky 2009-05-28  

一直在用struts2,struts1没做过真正的项目。

60 楼 黑暗浪子 2009-05-27  

jasstion 写道

你需要传递的数据少的话可以直接利用Request.getParetamter()不久行了，还有，一些不太复杂的业务逻辑你可以直接用Bean，像一些AJAX技术的应用。

struts2里面的action都有getter，setter方法，可以理解为半个Bean。
我觉的单论struts2还是有点实力和JSF一时瑜亮的，至于那个山寨JSF-tapestry我并不看好。
当然个人还是对ROR有崇拜之情。

59 楼 jasstion 2009-05-27  

你需要传递的数据少的话可以直接利用Request.getParetamter()不久行了，还有，一些不太复杂的业务逻辑你可以直接用Bean，像一些AJAX技术的应用。

58 楼 黑暗浪子 2009-05-27  

betafox 写道

黑暗浪子 写道

betafox 写道抖出这个帖子的目的是为了让大家分析一下各种开源框架在应用中存在的实际问题，不要动辄就struts2吧，个人认为这是回避问题，不是靓号的治学态度，呵呵，各有各的问题，没有一个东西是没有缺陷的。如果有必要再开一贴：鸡肋的struts2&nbsp; ??? 问题同样有一堆，呵呵，没必要啊
那你现在准备用哪一个？还是自己开发一个？
如果是自己开发的那个，说到底是想来个性化一下下。
欧美技术领域的一些技术已经成为行业标准，为什么中国人不好好守规则，还要别出心裁。
自己想证明中国人也能弄吗？
可以的确是可以。
但是就算做出来的，你以为别人会用吗？

呵呵，楼上激烈了，之前的帖子已经说过了，目的是讨论“欧美技术领域的一些技术已经成为行业标准的”的东西在具体应用中存在的水土不服问题，存在的标准化导致的细节兼顾不够的问题，是为了强调国人必须在标准的基础进行细节的修正从而定制更好的“应用层架构”，原则是站在巨人肩膀上更进一步，而不是重新发明车轮，对于这个初衷楼上可有疑义？

这语气和中国足协请洋教练时候的语气没什么区别。

57 楼 黑暗浪子 2009-05-27  

betafox 写道

黑暗浪子 写道

betafox 写道抖出这个帖子的目的是为了让大家分析一下各种开源框架在应用中存在的实际问题，不要动辄就struts2吧，个人认为这是回避问题，不是靓号的治学态度，呵呵，各有各的问题，没有一个东西是没有缺陷的。如果有必要再开一贴：鸡肋的struts2&nbsp; ??? 问题同样有一堆，呵呵，没必要啊
那你现在准备用哪一个？还是自己开发一个？
如果是自己开发的那个，说到底是想来个性化一下下。
欧美技术领域的一些技术已经成为行业标准，为什么中国人不好好守规则，还要别出心裁。
自己想证明中国人也能弄吗？
可以的确是可以。
但是就算做出来的，你以为别人会用吗？

呵呵，楼上激烈了，之前的帖子已经说过了，目的是讨论“欧美技术领域的一些技术已经成为行业标准的”的东西在具体应用中存在的水土不服问题，存在的标准化导致的细节兼顾不够的问题，是为了强调国人必须在标准的基础进行细节的修正从而定制更好的“应用层架构”，原则是站在巨人肩膀上更进一步，而不是重新发明车轮，对于这个初衷楼上可有疑义？

这语气和中国足协请洋教练时候的语气没什么区别。

56 楼 betafox 2009-05-27  

黑暗浪子 写道

betafox 写道抖出这个帖子的目的是为了让大家分析一下各种开源框架在应用中存在的实际问题，不要动辄就struts2吧，个人认为这是回避问题，不是靓号的治学态度，呵呵，各有各的问题，没有一个东西是没有缺陷的。如果有必要再开一贴：鸡肋的struts2&nbsp; ??? 问题同样有一堆，呵呵，没必要啊
那你现在准备用哪一个？还是自己开发一个？
如果是自己开发的那个，说到底是想来个性化一下下。
欧美技术领域的一些技术已经成为行业标准，为什么中国人不好好守规则，还要别出心裁。
自己想证明中国人也能弄吗？
可以的确是可以。
但是就算做出来的，你以为别人会用吗？

呵呵，楼上激烈了，之前的帖子已经说过了，目的是讨论“欧美技术领域的一些技术已经成为行业标准的”的东西在具体应用中存在的水土不服问题，存在的标准化导致的细节兼顾不够的问题，是为了强调国人必须在标准的基础进行细节的修正从而定制更好的“应用层架构”，原则是站在巨人肩膀上更进一步，而不是重新发明车轮，对于这个初衷楼上可有疑义？

55 楼 黑暗浪子 2009-05-27  

betafox 写道

抖出这个帖子的目的是为了让大家分析一下各种开源框架在应用中存在的实际问题，不要动辄就struts2吧，个人认为这是回避问题，不是靓号的治学态度，呵呵，各有各的问题，没有一个东西是没有缺陷的。如果有必要再开一贴：鸡肋的struts2  ??? 问题同样有一堆，呵呵，没必要啊

那你现在准备用哪一个？还是自己开发一个？
如果是自己开发的那个，说到底是想来个性化一下下。
欧美技术领域的一些技术已经成为行业标准，为什么中国人不好好守规则，还要别出心裁。
自己想证明中国人也能弄吗？
可以的确是可以。
但是就算做出来的，你以为别人会用吗？

54 楼 melode11 2009-05-27  

抛出异常的爱 写道

icewubin 写道

抛出异常的爱 写道

由于多线程关系所以尽量不要使用状态属性.....否则要七锁八锁的....很是麻烦.

在2中没这个问题吧，action属性的生命周期是一个request。

2也没有actionform这东西吧

struts1的form每次都new，没有线程问题。
倒是struts2的action让Spring来生成的话就必须指定为prototype，否则就会有线程问题。

53 楼 jcs7575 2009-05-26  

抛出异常的爱 写道

icewubin 写道

抛出异常的爱 写道

由于多线程关系所以尽量不要使用状态属性.....否则要七锁八锁的....很是麻烦.

在2中没这个问题吧，action属性的生命周期是一个request。

2也没有actionform这东西吧

2可以有 哈哈
默认没有 但是也可以像1那样用 支持的

52 楼 jcs7575 2009-05-26  

accphc 写道

jcs7575 写道

我认为action不就是做转发来用的
如果不用form那表单的数据传不过来啊

如果不用struts 如果用velocity也是一样需要有spring的controller 也需要有model的

你觉得呢？

为什么不用form表单数据传递不过来呢？
request.getAttribute()不是一样取么！！

倒是能取到，不过每次都是request.getAttribute("****") 总归不是很爽吧

个人习惯问题 呵呵

51 楼 betafox 2009-05-26  

抖出这个帖子的目的是为了让大家分析一下各种开源框架在应用中存在的实际问题，不要动辄就struts2吧，个人认为这是回避问题，不是靓号的治学态度，呵呵，各有各的问题，没有一个东西是没有缺陷的。如果有必要再开一贴：鸡肋的struts2  ??? 问题同样有一堆，呵呵，没必要啊

50 楼 betafox 2009-05-26  

<div class="quote_title">bingyunxl 写道</div>
<div class="quote_div">我觉得楼主的见解有以下问题：<br>1） 对DTO(数据传输模型)，Domain model(领域模型)，数据实体(Entity)之间的理解有些问题<br>2） 不同层拥有不同的职责，如果不分层，楼主完全可以在JSP页面中完成所有的事情。<br>3） Action其实就是做一些数据校验，将逻辑计算推到服务层<br>4） 数据的展示和数据的计算模型很多情况下不区分，但是不能说本质上没有区别，也有很多时候计算模型和展示模型不一致。<br><br>请参考</div>
<p><br><br>1、我的理解是这三个模型在概念上是要分离的，但是实战中为了避免过度分离的副作用，同一个class可以充当多个角色；<br>2、关于分层的必要性我没有意见，各司其职是应该的；我的意思是：层次这个东西在实战中可以体现为抽象的对象（就是通用类），在架构层面存在即可，而非必须在具体业务实现中体现该对象；<br><br>以action为例：我的意思不是要去掉这个层次，而是觉得抽象度不够（如果仅仅为了数据校验的话），在具体应用架构中有必要做进一步的抽象和提炼。</p>
<p>可以看一下这个：<a href="/topic/396024">http://www.iteye.com/topic/396024</a></p>
<p> </p>

49 楼 bingyunxl 2009-05-26  

我觉得楼主的见解有以下问题：
1） 对DTO(数据传输模型)，Domain model(领域模型)，数据实体(Entity)之间的理解有些问题
2） 不同层拥有不同的职责，如果不分层，楼主完全可以在JSP页面中完成所有的事情。
3） Action其实就是做一些数据校验，将逻辑计算推到服务层
4） 数据的展示和数据的计算模型很多情况下不区分，但是不能说本质上没有区别，也有很多时候计算模型和展示模型不一致。

请参考

48 楼 xiaominzi 2009-05-26  

直接用struts 2

47 楼 jeasony 2009-05-26  

呵呵，有同感，

46 楼 betafox 2009-05-26  

<div class="quote_title">sslaowan 写道</div>
<div class="quote_div">
<div class="quote_title">betafox 写道</div>
<div class="quote_div">
<div class="quote_title">sslaowan 写道</div>
<div class="quote_div">关于ActionForm，参见DTO模式，如果你的业务层实现为一个Rich Domain Model，那么DTO就很有用了<br><br>关于Action，参见Command模式，关于Struts核心的架构可参见《J2EE核心模式》<br><br>这个话题没什么好讨论的，如果你理解Struts的设计思想，那么你就会认为你这么使用，是正确的~~</div>
<br><br>理论上是正确的，确实如君所言没什么好说的，我也认为架构上应该遵循这样的层次，然则，理论化的东西在实战中往往不是效率最优的，相信这点大家都有体会，所以我才有此问。</div>
<p><br><br>这种东西都经过了理论-&gt;实践-&gt;理论-&gt;实践 无数回了，我从来不认为架构上就应该遵循这样的层次，我的观点具体请见我写的<a href="http://sslaowan.iteye.com/blog/375093">我们应该怎样看待框架</a>。</p>
<p> </p>
</div>
<p> </p>
<p>看了<a href="http://sslaowan.iteye.com/blog/375093">我们应该怎样看待框架</a>。写的很好很清晰，谨受教！</p>

45 楼 sslaowan 2009-05-26  

<div class="quote_title">betafox 写道</div>
<div class="quote_div">
<div class="quote_title">sslaowan 写道</div>
<div class="quote_div">关于ActionForm，参见DTO模式，如果你的业务层实现为一个Rich Domain Model，那么DTO就很有用了<br><br>关于Action，参见Command模式，关于Struts核心的架构可参见《J2EE核心模式》<br><br>这个话题没什么好讨论的，如果你理解Struts的设计思想，那么你就会认为你这么使用，是正确的~~</div>
<br><br>理论上是正确的，确实如君所言没什么好说的，我也认为架构上应该遵循这样的层次，然则，理论化的东西在实战中往往不是效率最优的，相信这点大家都有体会，所以我才有此问。</div>
<p><br><br>这种东西都经过了理论-&gt;实践-&gt;理论-&gt;实践 无数回了，我从来不认为架构上就应该遵循这样的层次，我的观点具体请见我写的<a href="http://sslaowan.iteye.com/blog/375093">我们应该怎样看待框架</a>。</p>
<p> </p>

44 楼 accphc 2009-05-26  

jcs7575 写道

我认为action不就是做转发来用的
如果不用form那表单的数据传不过来啊

如果不用struts 如果用velocity也是一样需要有spring的controller 也需要有model的

你觉得呢？

为什么不用form表单数据传递不过来呢？
request.getAttribute()不是一样取么！！