让我们开始看看struts的核心，这也是MVC框架的核心。Struts用the Service to Worker模式[Core]实现了MVC模式.
控制器对象
控制器实现了ActionServlet类。它集中处理所有客户端的请求。它清晰的划分了控制层的作用，处理视图和导航管理，保留模型处理和操作给请求处理器（Command objects[Gof]）处理。发布文档中定义了所有输入请求映射到中央控制器的描述，如下：
action
org.apache.struts.action.ActionServlet
所有URIs请求以do结尾的都映射到servlet中，如下：
action
*.do
匹配该模式的表单请求如下所示：
http://www.my_site_name.com/mycontext/actionName.do
映象前缀叫做扩展映象，然而，你也可以定义路径映象用/*结尾，如下
action
/do/*
对应请求：http://www.my_site_name.com/mycontext/do/action_Name
通过配置文件可以不用改变程序代码就可以改变映射的方式；这个映射方案也涉及到Mulitplexed Resource Mapping。对于所有表现层请求，控制器提供了一个集中处理点。控制器委托请求处理器处理每一个请求。请求处理器分配请求到相关的form bean处理表单校验，处理模型。控制器和请求处理器的联合构成了控制器处理机制的核心。由控制器提供的这种抽象减轻了开发人员创建公共应用程序服务比如管理视图，sessions，表单数据的劳动。开发人员可以遵循标准的机制处理例如：错误异常处理，导航，国际化，数据验证，数据转换等。
在Struts1.1中，struts的配置通过控制器的init方法加载。配置文件控制框架的行为；包括使用ActionMapping配置对象映射URIs 到请求处理器，配置消息资源，通过插件处理外部资源等。实际上ActionServlet委托所有输入请求给RequestProcessor，由它实际处理所有请求。
分配器对象
RequestProcessor把请求处理器和关联的form bean联合提供分派和处理客户请求的功能。form bean的错误创建，抛出异常和请求处理器都由RequestProcessor处理，并影响RequestProcessor的视图管理函数。form beans协助RequestProcessor存储表单数据，或者传递视图需要的模型数据。通过struts－config.xml的配置。所有请求被控制器委托给分配器，分配器是RequestProcessor对象。RequestProcessor根据action标识检查请求URI，利用ActionMapping配置对象（下一节介绍）的信息创建请求处理对象，调用requesthandler.execute方法。该方法和应用程序的模型交互。根据处理结果，请求处理器会返回一个ActionForward配置对象（ActionForward是带有元素的运行时表示，在使用ActionForward导航一节解释）给RequestProcessor。它会使用ActionForward对象通过调用RequestDispatcher.forward方法或response.sendRedirect方法激活下一个视图。
ActionMapping的命令模式（译注：本节翻译从简，因为涉及到具体语法。）
struts通过xml语法指定URI和servlet的映射。这个实现和GOf的命令模式非常相似。
模型和RequestHandlers的交互
Action的子类用来适配请求和模型。一个Action的子类也叫request handler，根据具体请求创建。一个action由RequestProcessor最先解释，并返回一个相关的request handler。对应每个请求创建的action的父类由分配器对象创建。request handler实现了命令模式。一个客户端请求在URI中封装了想要的行为，路径信息由分配器（RequestProcessor）提取并创建一个相关的请求处理对象实例。命令模式解耦请求处理和UI。
基本的Action类提供了公用的函数处理框架相关的资源和方法，保存子类execute方法执行时检测到的错误。这些错误通过使用在用ErrorsTag显示错误一节介绍的定制的org.apache.struts.taglib.html.ErrorsTag显示在html表单中。request handler的execute方法应该包含控制流程处理请求参数和相关联的ActionForm，它应该封装模型交互语法，提供基于模型操作结果的下一个视图。Request handlers由RequestProcessor在第一次创建时缓存，给其它请求使用；因此request handlers不能够包含用户特殊的状态信息；而且当需要串行处理时，request handlers必须加上同步机制处理资源。
对于分布式应用来说，一个action类包含和EJB组件中的业务逻辑交互的控制逻辑，类似于业务委托对象。业务委托使得request handlers不用直接处理复杂的分布式组件。因为处理服务端组件的逻辑被嵌入到业务委托中，所以业务委托设计模式使request handlers 和服务端组件松耦合。一个request handler由开发人员在表示层编写，然而一个业务委托通常由开发人员在创建业务层服务时编写。对于小的非分布式应用，action类可以包含业务逻辑。当不需要分布式处理和业务逻辑嵌入到request handlers中时，数据处理对象[Core]可以被用来提取数据处理的实现；它提供了request handlers和数据处理层松耦合，因此保证表示层不用实现中间层的变化。action的基类提供了方便的方法，请参考http://jakarta.apache.org/struts/api/index.html.的API文档
用ActionForward导航
ActionForward对象是配置对象。这些配置对象都有基于有意义名称比如'success','failure'等的唯一标识符保证可以被找到。request handlers使用封装了URL路径的ActionForward对象识别目的视图。ActionForward对象根据struts-config.xml的元素创建。例子略。