在基于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