主要问题:如果我的应用程序当前使用的是 Struts 1.x——并且我正在考虑迁移到 Spring-MVC 或 Struts2 以用于 MVC 框架——是否有任何一个可以更容易地从 Struts1.2 迁移?
澄清一下,我不是在问 SpringMVC 还是 Struts2 总体上是否更好(SO 上有许多现有的 Q 可以解决这个问题)——只是哪个更容易从 Struts1.2 迁移到。
从迁移的角度来看,我最感兴趣的一点是:继续(开始时)在 JSP 页面中使用 struts1.x 的 taglib 的可能性,同时在后端更改为 Struts2 的(或 SpringMVC 的)API。(换句话说,这些框架中的任何一个都可以支持 Struts1.x 的 taglib 作为插件)吗?[注意:这不是一个长期的解决方案——但会减少集成的痛苦,因为 JSP 不需要立即重写。我认为这个问题是有道理的——如果没有,请解释原因]
话虽如此,我当然对任何其他迁移优势感兴趣。
一些背景:
我正在开发一个应用程序,其 MVC 层是通过 Struts 1.2 编写的。我们也在使用 Spring IOC——尽管该应用程序目前在 Struts 层和 Spring 的 DI 设施之间没有强大的集成。(注意:这是我们计划在重构时纠正的问题,但我的理解是,通过一些计划 - 即使使用 Spring IOC + Struts2 组合,也可以正确/高效地完成。)
作为改进/重构代码库的一部分 - 我们希望升级到更现代的 MVC 框架(以消除对 Action/Form 类的需求,并尽可能使用基于注释的配置等)但保持整体经典-MVC 风格(即目前对过渡到 JSF、Tapestry、GWT、Flex、Play 等不感兴趣。我知道这些是非常不同的东西 - 将它们混为一谈只是为了给出一个总体思路。)另外,愿望是选择具有合理牵引力/动力的东西 - 因此出于这个原因将条纹排除在外。这似乎只会让 Spring-MVC 和 Struts2 成为竞争者(尽管如果还有其他具有类似风格和强大行业牵引力的东西 - 我们当然会考虑)
当然,切换到其中任何一个都需要减少工作量 - 但计划是在模块化级别上进行。出于这个原因,如果这些支持 Struts 1.2 的标记库中的任何一个 - 它会使切换/测试更容易(因为我们可以在新 API 中编写特定模块的“控制”实现 - 并让第二台服务器运行旧的 Struts1 .2 使用相同的 jsps 实现。QA 测试在某种程度上将是“苹果对苹果”。这是否有意义,或者这种方法(如果可行的话)会导致比它解决的问题更多的问题?
另外,如上所述,虽然我的主要问题是关于使用 Spring-MVC 或 Struts2 运行 struts1.2 的标记库 - 我也对 Struts2-vs-Spring-MVC 的任何其他迁移优势感兴趣。