Web措施从Struts向Stripes框架的移植
副标题#e#
摘要 把你的现有Struts应用措施移植到Stripes框架可以或许简化Web开拓，而且这一移植进程要比你想象的更为容易。
一、引言
把一个现有Java Web应用措施移植到一种新框架大概不是大大都开拓者最感乐趣的问题。除了要耗费时间进修一种新的Web框架外，譬喻标签、国际化系统和校验等沉重的转化进程大概会迫使每一位措施员思量再三。我最近就面对这样的一个挑战-从Struts举办移植。
在抉择移植一个应用措施前，应该首先问一下"为何不利用此刻的框架？"在我看来，Struts是一种不变的具有精采文档的框架，而且有一大批开拓者社区成员，可是其设置很贫苦，并且其表单、行为、应用措施流和校验的疏散有时会带来许多贫苦。这种景象在我的Struts应用措施不绝变大时加倍糟糕。最后，纯粹从一种维护的角度，我抉择把它移植到一种新的框架。
开始，我认为没有一种框架(Java ServerFaces，Tapestry，WebWorks，Spring MVC)值得从Struts迁移向其迁移。譬喻JSF这样的框架看上去极不友好。其它的，譬喻Tapestry和WebWorks，涉及到整页整页的看上去令人贫苦的国际化系统。而从设置角度来看，Spring MVC看上去并不比Struts好几多。我选择的框架应该仅需适当的进修时间，还要与移植效益相称；并且，它还必然要使我编码、排错与维护更为容易。
二、发明Stripes框架
厥后，我偶尔发明白Stripes框架。就象Java社区中的很多发热友一样，我一直跟跟着Ruby on Rails（RoR）现象。依我看来，Stripes是最靠近于RoR哲学的Java MVC框架-简朴，大度，而且要求最小的设置。除了它的简捷外，象我这样一位Struts措施员，Stripes很是适合我的口胃。应用措施流和很多定名老例都与之十分相似。Stripes中的ActionBeans就象Strut的Actions，而ForwardResolutions极象ActionForwards。因此，利用这一框架，我不必丢弃我所有以前的Struts常识。
别的吸引我的是Stripes文档。象框架自己一样，文档也是清洁、洁净而简洁。其标签库文档和API都具有精采的归档，并且该框架的每一种特征险些都有相应的示例源码。这些优秀的文档再加上我的现有Struts常识使我坚信，我可以快速地把握这种Stripes框架。
值得留意的是，Stripes还包罗别的一些使其成为一种精采的AJAX平台的特征，譬喻它提供了一种流式方案，该方案答允对AJAX实现举办改造的错误处理惩罚。然而，对付我来说，最终的抉择因素照旧我可以或许清楚地看到它会使我的糊口更容易些。我预计，在我的应用措施的行为/设置/校验部门，我只需利用约一半的代码就够了。更少的代码意味着了更少的错误、更快的开拓时间和更容易的纠错。
三、移植进程
我从视图层开始移植，然后再向行为层移植。事实上，我也没有很明晰的逻辑思路；只是必需从某处开始，而视图部门看起来更适合于作为一个起始点。
(一) JavaServer Pages
就象Struts一样，Stripes利用JSP来实现其视图层。我受惊地发明，Stripes标签库很是雷同于Struts的HTML taglib。事实上，我可以或许利用这种统一替换方法来进级我的很多标签。
Stripes依赖于JSTL实现JSP视图中的逻辑。我在我的应用措施中殽杂利用了Struts逻辑标签和JSTL。通过把我的所有逻辑标签移植到JSTL，我可以或许操作JSTL的优越的if/else和case语句的本领处理惩罚，它们大概是很原始的可能基础不存在于Struts逻辑taglib中。
(二) 国际化
接下来，我要移植我的Struts的动静资源。在设置端，所有要求的操纵就是重定名我的Struts动静资源文件。在我的JSP中，我可以或许利用统一替换方法把我的所有Struts message标签(譬喻，<bean:message key="buttons.save"/>)替换为JSTL名目的签(譬喻，<fmt:message key="buttons.save"/>)。这种JSTL名目的签还支持可用于Struts中的动静资源绑定。
#p#副标题#e#
(三) 表单
我的移植的最有意义的部门是去掉了我的Struts Action表单，这是在Action类中举办的，要求大量的XML标志和冗长的转换，如下例所示：
<form-bean name="employeeUpdateForm" type="org.apache.struts.validator.DynaValidatorForm">
<form-property name="employeeid" type="java.lang.Long" />
<form-property name="firstname" type="java.lang.String" />
<form-property name="lastname" type="java.lang.String" />
<form-property name="phone" type="java.lang.String" />
<form-property name="email" type="java.lang.String" />
<form-property name="phone" type="java.lang.String" />
<form-property name="socialsecurity" type="java.lang.String" />
<form-property name="birthdate" type="java.lang.String" />
<form-property name="salary " type="java.lang.String" />
</form-bean>
public ActionForward executeAction(ActionMapping mapping， ActionForm form，
HttpServletRequest request， HttpServletResponse response) throws Exception {
Employee employee=new Employee();
DynaValidatorForm eaf = (DynaValidatorForm) form;
employee.setFirstname(eaf.getString("firstname"));
employee.setLastname(eaf.getString("lastname"));
employee.setPhone (eaf.getString("phone"));
employee.setEmail (eaf.getString("email"));
employee.setEmployeeid ((Integer)eaf.get("employeeid"));
employee.setSocialsecurity(Long.parseLong(eaf.getString("socialsecurity")));
employee.setBirthdate(MyUtils.convertStringToDate(eaf.getString("birthdate")));
employee.setSalary(MyUtils.convertStringToBigDecimal(eaf.getString("salary")));
EmployeeDAOService.updateEmployee(employee);
return new ActionForward(mapping.getForward());
}
另一方面，Stripes表单处理惩罚答允你把你的域工具用作一个表单利用：
#p#分页标题#e#
public class UpdateEmployeeActionBean implements ActionBean {
private ActionBeanContext context;
private Employee employee;
public ActionBeanContext getContext() {
return context;
}
public void setContext(ActionBeanContext context) {
this.context = context;
}
public void setEmployee(Employee employee) {
this.employee = employee;
}
public Employee getEmployee() {
return this.employee;
}
@DefaultHandler
public Resolution update() {
EmployeeDAOService.updateEmployee(employee);
return new ForwardResolution("/employees/updateEmployee.jsp");
}
}
在大大都环境中，我可以或许嵌入我的域工具的一个副本作为我的Stripes ActionBean类的一个属性而且仅包罗涉及把该工具移入/移出我的耐久层的代码部门。我把所有表单处理惩罚都交给了Struts Action来实现，包罗初始化设置、把表单强制转换成适当的类以及从域工具中往返转换数据（约30％的代码是在大大都Action类中实现的）。在Stripes中并不需要这样。
简言之，把域工具作为你的ActionBean类的一个属性嵌入，为该类提供了getter和setter要领。总之，所有有趣的处所（包摆列表）都在HTML视图的表单中浮现出来。
所有我对表单的操纵也都可以通过查询串参数方法来实现。我仅把这些参数作为我的ActionBean的一个属性，而假如它们是请求的一部门的话，可以把它们自动地复制到相应的域中。
(四) 校验
与表单或标签移植对比，把Struts校验移植到Stripes要求更多的事情。在我的应用措施中，我必需在Stripes ActionBean类内部利用Java 5.0注解重写在validation.xml文件中的校验设置。Stripes还为你提供一种精采的基于范例的校验。当用户输入错误值时，不需要用户举办任何设置，Stripes就可以把HTML表单返回给他们（譬喻，在一个数字或日期域中的字符）。表单可以或许被自动返回并带有一条向用户友好显示的动静，最后堕落域被高亮显示。
(五) 应用措施流程
转换我的Struts应用措施的节制流大概是独一远离Struts思维的一个处所。在Struts中，节制流（URL请求绑定、行为和功效视图）都以XML标志形式生成而且被会合放到struts-config.xml文件中。在行为层外举办生成使Struts绑定更为机动。它们没有被硬编码到行为层中，而单个行为可以容易地与差异的输入URL和转发举办耦合。这种方法的欠好的处地址于，Struts设置量大概会急剧增加而成为贫苦。节制流与行为层的疏散还会使在整个请求周期中的调试相当坚苦。
为此，Stripes共提供了三种差异方法以便把请求映射到行为层：
1. 利用注解把一个ActionBean显式绑定到一个URL；
2. 答允Stripes在启动期间基于ActionBean类路径和应用措施URL之间的相似性揣摩它的ActionBean的绑定；
3. 类路径通过利用Stripes useBean标签，把一个JSP绑定到任何ActionBean，或挪用应用措施中一个Java类的任何要领。
尽量与Struts设置对比，前两种要领好像有点"硬编码"特征，可是useBean标签提供了大量的机动性。借助于该标签，JSP可以存取多个ActionBean或类以获得其所需要的内容。
四、结论
当选择一个新框架时，迁移的容易性（既包罗进修新框架方面，也包罗移植你的现有代码方面）是要思量的要素之一，可是不该该过多地强调。是的，你大概已经在进修一种现有框架上做出很大的投资而且在你的下一个MVC平台上保存这些投资的一部门更好一些。并且，假如你可以或许在几周而不是在几个月内移植完你的应用措施则最好不外。可是不管问题是何等容易或是何等愉快，你照旧要首先应该抉择是否方针可以或许满意你的真正要求。对付我来说，可以或许把险些一半的代码放到我的行为层中而把表单、设置和校验放到一起是我最体贴的问题。Stripe文档的质量及其它问题则为次要。
