要说Struts1的工作流程。就必需要说一下Model1和Model2了。由于这个框架是踏着他们的尸骨一步一步的发展起来的。
Model1开发模式，想想我们刚刚開始接触Java的时候，我们用的就是这样的模式了，一个jsp页面+处理业务逻辑JavaBean+负责处理数据的DaoBean。更有甚者，你能够在这里直接连接数据库获取数据。非常简单，非常好理解，开发起来速度足够快。没有繁琐的转换。非常easy上手，所以说要做一个小项目，使用Model1这样的开发模式，还是非常不错的选择。可是我们想象一下，假设说Jsp页面。纪要负责显示，还要负责业务逻辑，那么假设我们想更换一下的话，可想而知。我们要做的工作。将会是非常大的。另一个问题就是程序逻辑开发与页面设计纠缠在一起，既不便于分工合作也不利于代码的重用。这样的程序其健壮性和可伸缩性都不好。
Model 2引入了"控制器"这个概念，控制器一般由Servlet来担任，client的请求不再直接送给一个处理业务逻辑的JSP页面。而是送给这个控制器，再由控制器依据详细的请求调用不同的事务逻辑，并将处理结果返回到合适的页面。
因此，这个servlet控制器为应用程序提供了一个进行前-后端处理的中枢。
一方面为输入数据的验证、身份认证、日志及实现国际化编程提供了一个合适的切入点。还有一方面也提供了将业务逻辑从JSP文件剥离的可能。
业务逻辑从JSP页面分离后。JSP文件蜕变成一个单纯完毕显示任务的东西。这就是常说的View。而独立出来的事务逻辑变成人们常说的Model,再加上控制器Control本身，就构成了MVC模式。实践证明，MVC模式为大型程序的开发及维护提供了巨大的便利。
而Struts1能够说是Model2的一个增强版，来自客户的全部须要通过框架的请求。统一由ActionServlet接收（ActionServlet Struts已经为我们写好了。仅仅要您应用没有什么特别的要求，它基本上都能满足您的要求），依据接收的请求參数和Struts配置(struts-config.xml)中ActionMapping，将请求送给合适的Action去处理。解决由谁做的问题，它们共同构成Struts的控制器。 Action则是Struts应用中真正干活的组件。它解决的是做什么的问题，它通过调用须要的业务组件（模型）来完毕应用的业务，业务组件解决的是怎样做的问题。并将运行的结果返回一个代表所需的描绘响应的JSP（或Action）的ActionForward对象给ActionServlet以将响应呈现给客户。
这里要特别说明一下的是：就是Action这个类，它不应该包括过多的业务逻辑。而应该仅仅是简单地收集业务方法所须要的数据并传递给业务对象。实际上，它的主要职责是： 校验前提条件或者声明 调用须要的业务逻辑方法 检測或处理其它错误 路由控制到相关视图 。
我们来看一下Struts1的工作时的流程原理图！
相信通过看着一张图，加上前边的描写叙述，我们都能够非常清楚的了解了Struts1的工作流程及其执行机理！然后在跟大家说几点要注意的
ActionServlet是通过process()方法来处理所有逻辑的。
Aaction配置信息并非所有载入，而是找与截取的url相应的action配置信息，载入到ActionMapping中，也就是一个action相应一个ActionMapping。
ActionForm也并非每次都反射，而是会先推断一下request或者session中是否已经创建。假设没有。则创建一次。并保存在request或者session中。
Action处理类相同是先检查是否已经创建过。然后在操作。
并且struts1中的Action创建过程存在线程安全问题。
ActionServlet依据Action返回的ActionForward，调用processForwardConfig，进行页面导航。