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