如何将struts2转换为SpringMVC
我不想争论是否要从struts2进行转换-> SpringMVC。我有最好的理由这样做。这就是客户所要求/支付的。
我一年前就做过struts，也做过SpringMVC。我希望通过 xml 进行配置，而不是过多使用注释。
我的计划是：
- 采用每个 struts2 操作类，了解正在发生什么操作，然后创建一个干净的 API 来委托给业务层。此步骤不是必需的。它就在这里，所以我们可以重构任何有意义的东西。
- 为每个 struts 2 操作类创建一个 SpringMVC 控制器（大致）。
我知道这只是需要做的事情的表面。还有什么要补充的吗？
预先感谢，
安德鲁
I don't want to debate whether or not to undertake the conversion from struts2 -> SpringMVC. I have the best reason to do it. It is what the customer is asking/paying for.
I've done struts1 years back and I've done SpringMVC. I'm hoping to configure via xml and not use Annotations that much.
My plan is to:
- Take each struts2 action class, understand what action is taking place and then create a clean API for delegating to the business layer. This step is not required. It is here so we can refactor whatever makes sense.
- Create a SpringMVC Controller (roughly) for every struts 2 action class.
I know that is just touching the surface of what needs to be done. Anyone have anything else to add?
Thanks in advance,
Andrew
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果正确创建了 struts2 操作，那么服务层就已经有了一个干净的 API。希望 Struts2 应用程序已经在使用 Spring DI。 Struts2 对象可以重用。但 Web 层相对较薄，因此最好删除 struts2 操作的任何痕迹以简化进一步的开发，而不是留下奇怪的工件。
Struts 用户负责四个主要部分。
已经提到的 Action 类应该相当薄，它的主要目的是在对象到达视图的过程中对对象进行编组。 （要编组它们，需要设置表单参数并验证它们）。如果对象是从服务层获取的，那么您应该能够将大部分逻辑剪切并粘贴到 Spring 控制器中。如果你发现应该在服务层的逻辑，它应该被推到上面。
视图层中的标签我不太确定。如果可能的话，最好用 jstl 标签替换 struts 特定标签。 Struts2 没有庞大的标签集，标签之间应该有几乎一对一的映射，但您需要弄清楚该映射是什么（以及哪个标签库最好）。
验证 - 我不知道 Spring MVC 如何进行验证。
拦截器解决了横切问题，我不知道Spring拦截器是如何工作的。 Spring 可以通过 AOP 解决自定义拦截器的问题。
总而言之，网络层不应该具有很大的侵入性......而且我不确定您会获得什么。请注意，如果您当前的 S2 应用程序未使用 Spring DI，那么添加 AOP 非常容易，您甚至可以将操作的创建委托给 Spring。因此，我预计这种转换的回报很少。作为替代方案，使用 Spring MVC 开始构建您需要的内容可能会更容易，并将 struts2 操作转换为 Web 服务（json 非常简单）。然后，当您有时间在 Spring MVC 中实现它们时，将它们逐步拆解。转换意味着理解两个系统并映射它们，这是混乱且容易出错的...这具有相同的最终效果（删除 struts2 框架），但也可以提高生产力。
If the struts2 actions were created properly there would be a clean API to the service layer already. Hopefully the Struts2 application is already using Spring DI. Struts2 objects could be reused. But the web layer is relatively thin so it would be best to remove any trace of the struts2 actions to simplify further development, rather than leaving weird artifacts.
There are four main parts that a user of struts is responsible for.
The action class as already mentioned should be quite thin, it's main purpose is to marshal objects on their way to the view. (To marshal them it will need to set form parameters and validate them). If the objects are acquired from the service layer, then you should be able to mostly cut and paste the logic over into Spring Controllers. If you find logic that should be in the service layer, it should be pushed up.
The tags in the view layer I'm not so sure about. Probably best to replace struts specific tags with jstl tags where possible. Struts2 does not have a huge tag set, and there should be a pretty much one to one mapping between the tags but you'll need to figure out what that mapping is (and which tag lib is best).
Validation - I don't know how Spring MVC does validation.
Interceptors address cross cutting concerns, I don't know how Spring interceptors work. Spring could address the issue of custom interceptors probably with AOP.
All in all, the web tier shouldn't be very invasive... and I'm not sure what you'll gain. Be aware that if your current S2 application is not using Spring DI it is quite easy to add, along with AOP and you can even delegate the creation of actions to Spring. As such I would expect very little return in such a conversion. As an alternative, it might just be easier to start building what you need with Spring MVC, and turn the struts2 actions into web services (json is ridiculously easy). Then dismantle them piece wise when you have the time to implement them in Spring MVC. A conversion means understanding two systems and mapping them, it is messy and error prone... this has the same end effect (the removal of the struts2 framework) but would allow for productivity as well.