我使用Struts 1.2.4继承了这个巨大的遗留Java Web应用程序.我有一个关于行动的具体问题.大多数页面只有一个Action,而processExecute()方法是可怕的怪物(非常长且基于请求参数的嵌套if语句很多).
鉴于Actions是命令模式的一个实现,我正在考虑将这些Actions拆分为每个用户手势一个Action.这将是一个很大的重构,我想知道:
这是正确的方向吗？
是否有一个我可以采取的中间步骤,一个处理整体行动中的混乱的模式？Action中可能还有另一个命令模式？
Olaf Kock.. 9
我处理这个问题的方法是:
不做'一下子'
无论何时你改变什么,都要比你发现它更好
用单独的Action实现替换条件是一步.
更好的是:将您的实现与Action类分开,以便在更改框架时可以使用它
保持新的Command实现绝对不引用Struts,在这些实现中使用新的Actions作为Wrapper.
您可能需要为Struts ActionForms提供接口,以便在不复制所有数据的情况下传递它们.另一方面 - 您可能想要传递除ActionForms之外的其他对象,这些对象通常是一堆字符串(请参阅有关Struts 1.2 ActionForms的其他问题)
开始将零件迁移到更新更好的技术.Struts 1.2出现时很棒,但绝对不是你想要永恒支持的东西.现在有几代更好的框架.
肯定会有更多 - 对不起,我这里的时间不多了......
我处理这个问题的方法是:
不做'一下子'
无论何时你改变什么,都要比你发现它更好
用单独的Action实现替换条件是一步.
更好的是:将您的实现与Action类分开,以便在更改框架时可以使用它
保持新的Command实现绝对不引用Struts,在这些实现中使用新的Actions作为Wrapper.
您可能需要为Struts ActionForms提供接口,以便在不复制所有数据的情况下传递它们.另一方面 - 您可能想要传递除ActionForms之外的其他对象,这些对象通常是一堆字符串(请参阅有关Struts 1.2 ActionForms的其他问题)
开始将零件迁移到更新更好的技术.Struts 1.2出现时很棒,但绝对不是你想要永恒支持的东西.现在有几代更好的框架.
肯定会有更多 - 对不起,我这里的时间不多了......
在我看来,Struts Actions根本不应该有很多代码.它们应该直接与请求和响应交互 - 从表单或请求参数中获取一些数据,将该信息传递给服务层,然后将一些内容放入Response对象中,或者可以在用户的会话中保存一些数据.
我建议远离做动作类的继承.一开始听起来是个好主意,但我想迟早你会意识到你的事情比实际使代码库强大得多.Struts有足够的基本动作,如果你正在创建新的动作,你可能在Web层中得到了不应该存在的代码.
这只是我个人的经历.
京公网安备 11010802040832号 | 京ICP备19059560号-6 