struts2 每个（ajax）请求的action class-1 类？
在我的 struts 2 Web 应用程序中，网页上有几个菜单选项卡。这些菜单选项卡在单击时会触发 ajax 操作。所有这些操作都属于一个操作类。该操作类将请求路由到帮助器类。帮助器类有一个方法可以执行以下操作：
如果action = this，则执行此操作
如果行动 = 那，就这样做
依此类推....对于每个操作（即每个选项卡）。
有人可以对这个设计提出意见吗……这是 struts 2 的正确用法吗？或者我们应该有单独的动作类吗？ 另外，辅助类有什么标准做法吗？（即它应该是静态的、单例的、线程安全的等）
In my struts 2 web app, there are several menu tabs on a webpage. These menu tabs fire ajax actions when clicked. All these actions come to a single action class. This action class routes the request to a helper class. The helper class has a method that does :
If action = this, do this
If action = that, do that
And so on….for each action(i.e each tab).
Can someone offer comments on this design….is this a correct use of struts 2? Or should we have separate action classes?
Also, any standard practices for the helper class?(i.e should it be static, singleton, thread safe etc.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些想法：
使用 Action 类来处理多个 struts2 动作没有什么问题； struts2 允许您将特定操作路由到类的方法。如果类本身是一个有用的组织工具，那么这会很有帮助。例如，您可能有一个想要创建、读取、更新等的 Widget，而不是拥有一组会导致大量混乱的 CreateWidgetAction、ReadWidgetAction 等类，最好只拥有一个包含以下内容的 WidgetAction 类： create()、update() 等方法。鉴于您所描述的内容（不同的菜单选项卡），我猜它不太适合您的情况，但您当然可以做到。维护代码时需要查看的文件更少。
请注意，您将需要将不同的操作映射到这些不同的方法以及呈现结果的不同 JSP。
关于辅助类，我的建议是将视图+控制器相关逻辑放在 Action 类中，但将模型逻辑留在其他类（可能是您的辅助类）中。如果您的帮助程序类独立于表示来计算数据，那么这当然是合法的。但是，如果您的辅助类只是准备一个视图，请将逻辑放入 Action 本身中。
Couple of thoughts:
There's nothing wrong with using an Action class to handle multiple struts2 actions; struts2 allows you to route a particular action to a method of a class. That can be helpful if the class itself is a useful organizing device. For example, you might have a Widget that you want to Create, Read, Update, etc and rather than have a CreateWidgetAction, ReadWidgetAction, etc set of classes that will cause a lot of clutter, it's nicer to simply have a WidgetAction class that has create(), update(), etc methods on it. I am guessing it's less of a nice fit in your case, given what you describe (different menu tabs), but you can certainly do it. Less files to look at while maintaining code.
Note that you will need to map different actions to these different methods as well as different JSPs that render the results.
With regards to the helper class, my advice is to put view + controller related logic in the Action class(es), but leave the model logic in other classes (possibly your helper class). If your helper class is computing data independent of presentation, this is certainly legitimate. But if your helper class is simply preparing a view, put the logic in the Action itself.