要说Struts1的工作流程，就必须要说一下Model1和Model2了。因为这个框架是踏着他们的尸骨一步一步的发展起来的。
Model1开发模式，想想我们刚刚开始接触Java的时候，我们用的就是这种模式了，一个jsp页面+处理业务逻辑JavaBean+负责处理数据的DaoBean。更有甚者，你可以在这里直接连接数据库获取数据。很简单，很好理解，开发起来速度足够快，没有繁琐的转换，非常容易上手，所以说要做一个小项目，使用Model1这种开发模式，还是很不错的选择。但是我们想象一下，如果说Jsp页面，纪要负责显示，还要负责业务逻辑，那么如果我们想更换一下的话，可想而知，我们要做的工作，将会是很大的！还有一个问题就是程序逻辑开发与页面设计纠缠在一起，既不便于分工合作也不利于代码的重用，这样的程序其健壮性和可伸缩性都不好。
Model 2引入了"控制器"这个概念，控制器一般由Servlet来担任，客户端的请求不再直接送给一个处理业务逻辑的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，进行页面导航。
原文地址：http://blog.csdn.net/zhanghongjie0302/article/details/46346571
