【IT168 分析评论】
    至少可以这么说，把一个现有的Java Web应用移植到一个新的框架下是会使人厌烦的。象标签，国际化体系以及有效验证等事情在转化过程中足够打消开发者移植的勇气。但是有时新的框架带来的好处还是超过了移植的代价。  
    当Rick Smith在应用Struts时，他发现自己正面临着繁重的表单过程的配置和分离。对于他，一个移植是有意义的，但他考虑的大部分框架都有自身的问题，从而使他对移植很气馁。在他发现Stripes之前，一直是这样。在最近的文章中，Smith描述了从Struts到Stripes的历程。
    和许多Java团体中的人一样，我一直在注视Ruby on Rails (RoR)现象。对于我Stripes是与RoR体系最近的Java MVC框架：简单，优雅，要求最少的配置。除简单之外，对于象我这样的Struts老手，Stripes看起来很亲切。应用流程和一些的命名协议更相似。Stripes的ActionBeans和Strut的一样。ForwardResolutions ActionForwards看起来更加相像。有了这个框架，我不必将辛苦学到的Struts知识丢弃。另外一个决定性的因素是Smith估计他可以将应用中行为，配置，验证区中的代码总行数减少一半。依照Smith所说，从Struts移植到Stripes一般很容易，归结于几个因素。
    例如，Stripes有和Struts相似的标签库，而且Smith能通过全部替换方式利用JSTL格式化标签来替换他的所有Struts消息标签，同时对于Stripes表单处理他能够去除扩展的的Struts行为表单，允许使用区域对象作为一个表单。谈到有效性验证，Smith描述到，在没有用户配置的情况下，当他们输入错误的类型值时Stripes会返回给用户HTML表单，不只如此，Stripes自动会附加一条用户友好消息，而且错误的地方被加亮显示。
    转换Struts应用的控制流程可能有一个地方需要打破Struts 的思考方式，在Struts里，控制流程—URL绑定请求，动作和因此产生的视图，提交给XML标记被并集中在Struts-config.xml文件里，这种在Action层外部的提交使Struts绑定很灵活。在Action层内部并不是硬编码的，一个单一行为能被很容易地与不同的URL输入连接上。这种方法的不利，在于Struts配置会快速地增大而变得繁重。从Action层将控制流程分离也会让通过请求周期来调试自始至终都变得困难。
    Stripes提供3个不同方式来对Action层提出要求：
    1、使用事务来具体绑定一个ActionBean到URL中。
    2、允许Stripes在启动期间基于ActionBean类路径和应用的URL之间的相似性去猜测它的ActionBeans绑定。
    3、绑定一个JSP到任意的ActionBean，或者在应用的类路径中使用Stripes的useBean标签调用一个Java类的任何方法。
当前两个步骤与Struts配置比较起来似乎有些硬性编码时，useBean标签提供了很大的灵活性。有了它，JSPs能够访问多个ActionBeans或者类，以获得它们所需要的。
    考虑移植到新的框架，Smith承认不费力气的移植并不是一个决定性的因素。在从Struts到Stripes经过相当简单的移植过程后，Smith说，，他能维持他的一部分投资，这是很不错的。
    对于移植你的经验呢？什么样的框架让你最有收益呢，怎么才能使一个新的框架值移植更优良的呢？