表示层问题

1. 当浏览器发送一个Http请求，web容器是如何接受这个请求并指定相应的java类来执行业务逻辑并返回处理结果的？

该问题简称为URL Mapping问题。解决这个URL Mapping问题的核心在于建立一套由Http协议中的URL表达式到Java世界中类对象的规则匹配引擎

2. Web应用是典型的“请求-响应”模式的应用，数据是如何顺利流转于浏览器和java世界之间的？面对http协议与java世界数据形式的不匹配性，我们如何能够在流传时做到数据类型的自动转化？

在浏览器中，数据总是以字符串形式展现出来，表现出“弱类型”的特征；在java世界中，数据则体现为一个个结构化的java对象，表现出“强类型”的特征。解决数据流转问题的方案是使用表达式引擎。将表达式引擎插入到程序逻辑执行之前，我们就能从复杂的对象转化中解放出来，从而进一步简化开发流程。

3. web容器是一个典型的多线程环境，针对每一个http请求，web容器的线程池会分配一个特定的线程进行处理。那么如何保证在多线程环境下，处理请求的java类是线程安全的对象？如何保证数据的流转和访问都是线程安全的？

传统的表示层框架对于这个问题的处理方式是采用规避问题的方式（鸵鸟算法），另外一种解决方案就是在整个请求周期中引入ThreadLocal模式，将整个过程的对象访问都线程安全化，彻底解决多线程环境下的数据访问问题。ThreadLocal模式的引入为框架摆脱web容器的依赖铺平了道路

4. View层的表现形式总是多种多样的，随着web开发技术的不断发展，MVC如何在框架级别提供一种完全透明的方式来应对不同的视图表现形式？

解决这个问题的最有效途径是把不同的视图技术进行分类，针对不同的分类封装不同的视图跳转逻辑，而最重要的一步是将这两者与生产线有机结合起来。

5. MVC模式虽然很直观地为我们规定了表示层的各种元素，但是如何通过某种机制把这些元素有机整合在一起，从而成为一个整体呢？

MVC虽然在概念上被规定下来，在实现上却需要一个完整的机制来把这些元素都容纳在一起。通常情况下，我们往往把这种机制称之为配置元素。配置元素是构成程序的重要组成部分，他把各种形式的程序通过某种配置规则联系在一起。之前我们提过的URL Mapping实际上也属于配置规则，视图的跳转也是配置规则的一种。只有当这种配置规则被建立起来，MVC模式才能真正运行起来。

这一系列配置元素在框架内部往往被定义成统一的可以被识别的数据结构并在系统初始化的时候进行缓存。而这些被缓存了的对象，也成为主程序的控制流在MVC框架中各个元素之间进行流转的依据。

如果从元素的表现形式上看配置元素和控制流的关系，我们实际上可以看到整合过程的两个层面：数据结构和流程控制。所谓的框架，我么也只是在这两个层面上做文章，一方面规定好这些配置元素的定义，另一方面制定程序运转的流程，从而控制和整合散落在各处的表示层元素

参考：整理归纳自《struts2技术内幕——深入解析struts2架构设计与实现原理》