Web程序从Struts向Stripes框架的移植(2)

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文档的质量及其它问题则为次要。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有