一，使用Servlet来处理请求响应
当客户端提交数据之后，接着发送请求，请求被封装成对象，服务器接收到请求，根据请求的URL，来判断将请求对象交由哪个Servlet处理。在servlet中，我们可以根据请求是从哪里发出的，来判断我们具体执行哪段处理表现层业务逻辑的if-else.或者，可能我们客户端会提交一个参数，我们可以根据参数来判断调用哪段代码去渲染表现层，返回给客户端。无论是怎么判断，中间的选择都是要得出我们要返回哪个表现层，例如，返回哪个JSP！
当表现层越来越多的时候，我们的选择逻辑越来越庞大，而且，每次增加一个表现层，我们就要在servlet里面，if -else进去返回这个表现层的界面逻辑代码。首先，if-else过长是一个问题，而且，每次修改代码，严重违反了我们的开放封闭原则。
其实，使用了servlet之后，已经有明显的MVC的思想了，形式上也有MVC的意思，只是一些小的不足，改进这些不足，就会诞生更成熟的MVC实践。
首先是改进IF-Else的问题，针对我们以前的设计经验，if-else过长，我们选择的是工厂+反射来改进。这样，在这里，我们就拆出来很多处理请求响应的类，另外，反射是依赖配置文件的，所以，也会多出来一个配置文件，来配置我们在动态调用的时候，具体实例化哪一个类来处理请求响应。if-else处理掉了，所以后面的开放封闭的问题也就不存在了。
基于上面这个思路实现的MVC框架，想象中还是蛮美好的。
二，sturts的请求响应分析
下面来分析下struts中，是如何处理请求响应的：
前面过程其实一样，首先客户端发送请求，请求地址是符合我们servlet配置的url-name的，所以当服务器接收到请求的时候，创建完请求响应对象，会根据我们配置的url-name截取出URL，然后通过各种判断，之后，找到处理这个请求响应的类，当这个类处理完成之后，会返回一个专向的信息，信息里面至少包含：转向地址（转到哪里去），和请求响应信息等。
之后，我们的前端负责界面展现的servlet（在框架中已经被做好了）会帮我们将响应分发给相应的视图。
加入了struts之后，相比直接使用Servelt，我们屏蔽掉很多细节上的实现跟代码上的坏味道，让开发过程中更关注相对变化的东西。
