一。使用Servlet来处理请求响应

                 当client提交数据之后。接着发送请求，请求被封装成对象，server接收到请求，依据请求的URL。来推断将请求对象交由哪个Servlet处理。

在servlet中，我们能够依据请求是从哪里发出的。来推断我们详细运行哪段处理表现层业务逻辑的if-else.或者。可能我们client会提交一个參数，我们能够依据參数来推断调用哪段代码去渲染表现层。返回给client。不管是怎么推断，中间的选择都是要得出我们要返回哪个表现层，比如。返回哪个JSP。

               当表现层越来越多的时候。我们的选择逻辑越来越庞大，并且，每次添加一个表现层，我们就要在servlet里面，if -else进去返回这个表现层的界面逻辑代码。首先。if-else过长是一个问题，并且。每次改动代码，严重违反了我们的开放封闭原则。

            事实上，使用了servlet之后，已经有明显的MVC的思想了。形式上也有MVC的意思，仅仅是一些小的不足，改进这些不足，就会诞生更成熟的MVC实践。

         首先是改进IF-Else的问题，针对我们曾经的设计经验。if-else过长。我们选择的是工厂+反射来改进。

这样。在这里，我们就拆出来非常多处理请求响应的类。另外。反射是依赖配置文件的，所以。也会多出来一个配置文件，来配置我们在动态调用的时候。详细实例化哪一个类来处理请求响应。if-else处理掉了，所以后面的开放封闭的问题也就不存在了。

       基于上面这个思路实现的MVC框架，想象中还是蛮美好的。

二。sturts的请求响应分析

以下来分析下struts中，是怎样处理请求响应的：

       前面过程事实上一样。首先client发送请求。请求地址是符合我们servlet配置的url-name的。所以当server接收到请求的时候，创建完请求响应对象，会依据我们配置的url-name截取出URL，然后通过各种推断，之后。找到处理这个请求响应的类，当这个类处理完毕之后，会返回一个专向的信息，信息里面至少包括：转向地址（转到哪里去）。和请求响应信息等。

      之后，我们的前端负责界面展现的servlet（在框架中已经被做好了）会帮我们将响应分发给对应的视图。

      添加了struts之后，相比直接使用Servelt，我们屏蔽掉非常多细节上的实现跟代码上的坏味道。让开发过程中更关注相对变化的东西。