讓我們開始看看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的元素創建。例子略。