do coding(); while alive();

参考文档 : [原创] Web表现层的Client端设计模式探讨

这里提到的表现层应当是指包含Server端的展现相关的逻辑以及浏览器中的逻辑。在传统的开发方式中表现层逻辑往往只涉及到Server端，而到了Client端已完全变成了HTML+CSS或XML+XSLT毫无设计模式可言。笔者认为随着技术的发展和AJAX的推动，我们有必要将一部分表现层逻辑推向浏览器已进一步增强界面的交互能力。

或许目前大家设计的WEB页面还很少需要考虑对展现数据的管理。但是一旦有一天我们拥有了一套好用的UI组件库，那时我们设计的用户交互界面的复杂度也就会突破目前我们习惯认为的上限。想像一个稍微有点复杂的场景，如果我们拥有了一个像Excel一样的可以对任意单元进行实时编辑的Grid组件，用户可以对其中的数据做任意的增删改操作，那么我们就必须要考虑一下如何将用户所填入的数据以合理有效的方式提交回Server端了。
 
CS中的展现数据模型对象

不过真的要来设计一种在表现层中的数据模型，还真是有点千头万缕、无从下手。所以在具体考虑如何管理这些数据之前，我们先来看一看在传统的CS应用中数据是如何进行管理的，有没有什么可以借鉴的东西？不约而同的，在这些开发模式中都能找到一种专用的数据模型对象，在VB中它叫ADO.RecordSet、在Delphi中它叫TDataSet、在PB中它叫DataWindow。它们都有一些共同的特点：

1.       表驱动的结构, 具有当前记录的概念。
表驱动的设计模式是由关系型数据库自然衍生过来的设计方式，这种设计非常有利于用户对数据的浏览和编辑，也符合我们对同结构批量数据进行浏览和编辑的一般理解和习惯。

2.       控件可直接与数据模型进行绑定。

数据敏感控件与数据模型进行绑定，并自动的展示、修改或控制其中的数据，这是CS中最常用的一种开发模式。其核心原理就是设计模式中的观察者模式。数据模型是被观察者，控件是观察者。当数据模型中的数据发生变化时，会主动的通知绑定的控件做相应的刷新动作以实时的体现最新的数据。对于支持数据修改或控制操作（例如：翻动记录的操作）的控件，如果用户利用其对绑定的数据模型中的数据或状态做了改变，那么这种改变自然也会实现通知给所有其它相关的控件中。
 

但是在现在的 Java 的 BS

employee.getName(); 
 employee.isMarried(); 
 … … … 
 employee.setName(“Henry”); 

 dsEmployee(“name”); 
 dsEmployee(“married”); 
 … … … 
 dsEmployee(“name”)   =   “Henry”; 

4.       都具有一定的数据校验功能及支持一些与展现相关的属性。
数据对象中的列描述对象在描述属性名和数据类型的同时，往往还包含了其它一些跟显示和编辑有关的特性，例如：readOnly、format、validator等。以readOnly属性为例，当我们将数据模型中某个列的readOnly属性设置为true后，所有与该列相关的数据敏感控件都将变成只读的状态。这样的好处在于开发人员在编写页面逻辑时不必过多的考虑页面上堆砌了那些元素，而之需要关注他要处理怎样的数据操作逻辑，页面上大部分的操作逻辑或显示逻辑都将围绕数据模型对象而展开。

5.       支持事件。它们都拥有类似beforeChange、afterChange、beforeDelete、afterDelete这样的事件，以便于开发人员能够利用这些事件提供一些简单的数据校验或操作逻辑。

BS中的展现数据模型的初步设想

CS下的这些数据模型对象在早些年都有着成功的实践。试想，能不能把这种在CS下的表现层设计模式移植到BS的开发当中呢？不过鉴于BS架构更高的复杂的这个任务并不简单，按照我的设想经过移植的系统架构大致可能如下：


图中数据模型对象被拆分成了两个部分，即Server端的实例和Client端的实例。当我们要将数据从Server端传递到Client端时，系统首先应在Server端构建一个基于Java的数据模型，该数据模型对象的数据取自BO提供的VO。当然，如果Server端原本使用了JSP＋Bean的开发模式，数据模型对象也可能直接取自JDBC的ResultSet。而后数据模型对象将利用一套实现已封装好的规则，将数据以XML等方式输出到Client端。此时Client端的可视化控件就可以对数据进行浏览和操作，如果用户通过可视化控件对数据做了修改，这些脏数据也将暂时被缓存在Client端数据模型对象中，知道用户最终点击了提交按钮，此系统再利用AJAX机制将数据同步回Server端并执行进一步的后台处理。
 
看起来我们好像已经有了一个很好的开局！不过笔者认为在BS架构中完全照搬CS中的那套设计思路可能并不是最佳的方案。主要原因在CS中的这些数据模型都是按照表结构驱动的方式设计的，其基本思路类似关系型数据库中的表。而我们在J2EE的设计模式中更常使用的却是模型驱动的设计方式。表结构驱动自认有它的有点，易于理解，方便使用。不过他也有一些致命的缺陷，特别是它不能很好的描述数据对象之间的关系，每当我们试图使用表驱动的模型来描述递归，树，主从关联这样数据关系，总是会感觉束手束脚。无疑，基于OO的对象模型的结构是一种更好的数据描述方式，它往往能够更加准确的、真实的表达数据之间的关系。 

(未完待续...)