Web分层设计研究（二）

表现层设计（二）

       转自：http://blog.csdn.net/lemonfamily/article/details/1680677
        在上一次中，我将数据的封装的职责部分移交给了表现层，已经有一定的页面显示逻辑处理功能，而在纯MVC中，只有控制器层才负责数据的封装，事实上这样做会让servlet的request和response对象过度的渗透到我们的框架中，而这两个对象本来应该只在表现层中活动，出现在控制器层无疑将web容器的servlet对象都暴露给了控制器。在真正的分层设计中，控制器层有其他更重要的工作要做：数据分发与服务查找。这个，暂且放到下次再讨论。

       有了思路，我们如何设计出职责分明的表现层呢？这里我提供两个解决方案供参考：

 第一种方法，把表单数据—javabean的映射交给系统自动处理，系统对每个客户端的请求首先缓存起来，并用一个唯一的key进行标识（如sessionid）。只要在配置文件中指定javabean的具体类，并在客户端的表单页面对应项做一定的处理（名称对应）就能轻松的实现数据映射。我们要做的，可能只需要编写3行代码：（1）强制类型转换basebean为具体类型。（2）调用控制层的访问接口并取出数据；（3）返回一个供系统跳转或请求分发所需的标识。正是这种简约的调用风格，我们可以继续尝试把这3行代码简化，成为一个标准调用方式，如果在一个不需要太复杂的显示逻辑的web系统中，我们甚至可以不用去编写一行表现层的代码（当然配置还是要写的）。结构如图： 

 

       第一种方法的优点也是它的缺点，由于过度的依赖javabean与表单的映射，必然造成一个请求对应一个javabean，即使是客户端只发送了一个请求参数（这种情况远比发送一个大表单数据来得频繁）。可能会有人耍小聪明把很多个表单的数据都集合到一个javabean中，这样似乎只调用一个javabean就足够了，然而这样必然给数据的读写带来不小的麻烦。在大部分的框架中，对javabean读写都是通过自省与反射这种比较耗性能的方式处理的，处理大的javabean对象和处理一个字符串相比性能明显要差上好几个数量级。更糟糕的是如果修改了某个表单的一个项，可能会牵扯到其他表单对应名称的项，并不利于维护。因此折中的办法是，将几个操作同一个对象（可以是数据库表，也可以是某个页面或文件）的javabean整合到一起，并尽量避免使用大的javabean封装只有一个参数的请求数据。

       为了避免上面的这种问题，于是就有了第二种解决方案：

 

       第二种方案把数据的封装延迟到servlet的一般类中，当我们不需要把请求参数封装到javabean中时，只需要逐个取出request中的数据再传递给控制层就可以，如果需要，只要调用预先写好的beanutil类进行封装，事实上，我们并不一定会多写几行代码。就表单—javabean的映射而言，代码同样是3行：（1）利用beanutil把request中的数据拷贝到javabean中。（2）调用控制层的访问接口并取出数据；（3）返回一个供系统跳转或请求分发所需的标识。

       在数据转发设计中，一般都需要上层提供一个转发标识，这个标识一般来说都是字符串形式，系统通过匹配对应配置文件的标记来达到流程控制的目的。对于一些globle型的标记，比如异常、错误、无权访问等等，应该放在顶层的servlet中，然后在配置文件中定义这些globle标记的统一地址。

      现在来考虑如何设计表现层中的中间层，在这个层次中，我们要考虑如何对控制层传递的数据进行格式化输出。显示逻辑存在不同的需求，可能出于权限考虑，或出于个性化考虑，也可能出于某些特殊角色或特定场景的显示要求考虑等等。如果为每个不同需求定制一个格式化输出方法显然会很烦琐（当然特定系统可以这样做）。因此最好的方法是提供统一接口交给开发人员自行设计，系统只做有关全局标识的格式化输出处理。这里推荐的一种做法是使用xml—xsl方式进行格式化输出。只要上层提供足够的信息并组装成xml（javabean转换成xml并不很难），表现层就可以调用不同的xsl文件对xml进行解析并格式化输出，而且解析任务可以交给客户端浏览器处理（如果安全性要求不高的话）。完全可以满足各种不同的输出需求。

      由于需要考虑比较多的显示逻辑，表现层不能过多的限制开发人员对web容器的servlet的直接访问能力，否则有些业务需求实现起来会变的相当麻烦，特别是对客户体验要求比较高的系统更是如此。选择或自行设计表现层框架时就要对灵活性、稳定性、可维护性和效率方面权衡再三。