在Struts2中，控制器将一个Request调度给一个Action，Action将它传递给后端逻辑，后者可以被视为一个非常大的“模型”，用于处理请求，JSP代表Views。
如何在Struts2中定义Action？绝对不是View ......它是控制器还是型号？
Struts动作是MVC模式意义上的控制器。我认为值栈和ActionContext的讨论，以及动作类中的getter方法都会混淆这个问题。通常，这些只是其他对象（通常是Model对象）的容器。
虽然@AndreaLigios指出您可以使用各种get方法从操作中检索对象，但这更多的是通过赋予其通常分配给模型对象的附加职责来稀释动作内聚。是的，当您考虑做（或应该做）时，评估对象的责任非常重要。
简而言之，所有MVC框架中主要组件的职责如下：
当您查看特定的MVC框架（如Struts（或Spring MVC））时，您会发现框架通常同时提供Controller和View组件，但您自己构建模型是您的工作。即便如此，Struts还提供了大量额外的对象和组件，如ActionContext，可以更轻松地从View组件访问Model对象。
它绝对是（控制器的一部分），但它也是（模型的一部分）。
我的2美分：
......在Struts2中，Controller由负责读取，解释和操作请求的所有东西组成，以便提出适当的响应，因此是，Action是控制器，以及拦截器堆栈中的每个拦截器，我们可以扩大意义，包括Filter，ActionMapper等。
... Struts2是一个Pull-MVC框架：
使用视图层获取数据（即要渲染的模型）可以更好地理解Pull-MVC和Push-MVC。在Push-MVC的情况下，控制器构造数据（模型）并将其放入视图层，方法是将其放入范围变量（如请求或会话）中。典型的例子是Spring MVC和Struts1。另一方面，Pull-MVC将通常在控制器中构造的模型数据保持在公共位置，即在动作中，然后由视图层呈现。 Struts2是一种基于Pull-MVC的架构，其中所有数据都存储在Value Stack中，并由视图层检索以进行渲染。
然后在Struts2中，Value Stack是Model，并且Action被推到ValueStack的顶部（顶部）。因此，行动是模型的一部分。我们可以扩展Model的含义以包含整个ActionContext（包括其所有范围 - Page，Request，Session ......）
然后，当你在execute()方法中时，Action就是控制器，并且它是存储你通过getSomething() getter方法从JSP获取的属性的模型。
现在，重要的是：不要使用ModelDriven：o）
该操作绝对接近作为控制器而非模型的术语。特别是如果你使用REST与Struts2，你可以阅读Mapping REST URLs to Struts 2 Actions。
动作或控制器？大多数Struts 2开发人员都熟悉Action。它们是传入请求执行的事情。在REST插件的上下文中，为了让您保持警惕，我们将采用RESTful术语并参考我们的操作作为控制器。不要混淆;这只是一个名字！
控制器负责处理请求并返回视图作为结果。这就是Strust2中的行动。
用户经常将其模型与控制器聚合的事实不会错误地放置控制器定义。然后，如果一个控制器有一个模型，那么你可以认为它是大模型的一部分。它不是。
从未如此重要的部分是模型和视图的沟通。在Struts2中，它是通过动作上下文执行的。视图应该有权访问操作上下文以检索模型。这是由OGNL连接的。
框架将OGNL上下文设置为我们的
ActionContext，并将值堆栈设置为OGNL根对象。
在当前版本的Struts中，动作/控制器被推送到值堆栈，并以与模型相同的方式访问。这是无害的操作，因为控制器是线程安全的实例。为什么不像模特那样重复使用它们？
将模型对象聚合到控制器并从那里访问它们也是无害的。您可以将任意数量的模型关联到同一个操作。但是如果你考虑一个模型，那么你可以使用ModelDriven动作。但不建议使用最后一个，因为它给Struts2应用程序的体系结构带来了不必要的复杂性，并且不幸的是容易出错。