随着互联网的普及，浏览器已经成为当之无愧的信息展示方式，主要是基于不需要安装客户端软件，对于用户的接入门槛很低，同时丰富的UI展现方式和标准化的解析方式构成了它现在这种局面的原因。
浏览器通过URI调用WEB服务器，WEB服务器解释请求方的URI并调用服务端程序来处理这些请求。对于如何解析请求，看往过去我们发现有这么几种方式。
最早期开用的是一些服务端的小程序，例如java中的servlet或是CGI脚本，这个可以统称为服务端脚本方式。这些脚本能够很好的解析请求中的参数，并选择合适的子程序，组后通过流的方式将结果输出到浏览器。但是它的缺点很明显，将页面展示的渲染也放在脚本中(servlet)中，这个对于程序员来说是非常痛苦的，同时像java这种解释执行的语言，若是简单修改可一个页面，都需要重新编译，发布。

所以就出现第二种方式，服务器页面。将页面输出通过在服务端构造，对于其中的动态参数用脚本的方式替代，并在输出到浏览器前进行渲染，明显的例子就是jsp，php，freemarker等前端展示技术。同时将请求的解析及具体子程序的调用放到了脚本中。
服务器页面的方式是将页面的渲染和请求的解析和业务处理进行了剥离，但是随着业务复杂度的增加，也会面对领域层同样的问题，就是代码副本，后来就出现了MVC模型。

• 模型：负责领域逻辑


• 控制器：处理请求


• 视图：基于模型创建应答消息

一条请求进入输入控制器，控制器从中获取数据并调用合适的领域对象处理业务逻辑，领域对象和数据源交互，并根据消息的请求处理数据并返回，控制器根据返回结果选择合适的视图显示应答消息。输入控制器和视图中不直接交互，通过一个请求级别的会员共享数据，这个数据根据需要有不同的生命周期，有page，request，session，application等。同时控制器还需要将一个领域对象的结果转化为一个表现层展示对象，若是不同页面之间的这些领域对象和表现层对象转化逻辑非常类似的话，我们可以再抽取出一个应用控制器来处理这部分工作，但是更多的时候应用控制和输入控制器是一个。
到现在为止，输入控制器就作为了页面和领域对象的中间层。

早期的时候MVC模型中 jsp是承担了控制器和视图的功能，javabean作为业务模型，但是这种模式并没有很好的分离控制器和视图，容易造成代码的冗余，这种形式历史上称为mvn model 1 .后来对于控制器这个角色交给了服务端脚本就是servlet,如此就进化到了mvc modle 2 。

对于视图的展示存在二种模式：
1.转化视图 常见的就是XSLT，领域对象通过XML方式的存在
2.模板视图 这个是我们现在最流行的，常见的例如就是freemarker，jsp等，通过预定义的标签，来动态的加载数据。

对于使用的技巧就是会对一些多个页面公用的东西进行封装，例如宏等手段！