【IT168 技术文档】一、引子
这个blog已经荒废将近一年了，久也不写，自然有很多的理由，但更多的怕是懒吧。不说闲话了，转入正题。
关于基于JavaScript的RIA客户端数据处理这个话题，我打算分成两篇文章来写，一篇陈述我所总结出的基于B/S结构的RIA客户端数据处理的问题，另一篇则陈述针对这些问题我所提出的技术解决方案构架。
二、RIA?RIA!
关于RIA尤其是基于Ajax的RIA怕是屡见不鲜了吧?尤其是在Google推手之后，文字处理、表格处理、幻灯片放映这种看起来非常客户端的应用，都可以采用Ajax的技术来实现了。作为一个关注企业级应用开发的技术人员，一个很自然的想法就会产生，是否可以采用这种技术来改进我们基于Java EE技术开发的B/S结构的企业应用呢?
先说有没有必要，答案是肯定的。B/S被广为诟病的一个问题就是降低了最终用户的操作效率，以我的经验来说，用户虽然普遍的感到基于浏览器的界面要漂亮得多，用鼠标操作也很直观，但是却实在比以前的界面复杂而且操作困难。而且每次页面提交后的等待也实在是对工作效率的一个降低。当然，我这里也没有必要意义列举B/S在客户端的缺点，实际上这个问题是被广泛认同的。
再说可行性，可行性分为两种：技术上的可行性以及工程开发上的可行性。
技术上的可行性就无须验证了，Google Reader、Gmail、Google Docs的稳定运行都是非常好的证明。
但是它是否一定适合时间要求相对比较严格的工程开发呢?
这就需要一个非常稳定的平台来进行支持，而且由于工程开发的特殊性，最好还要有可视化的开发和调试环境才更有说服力。目前看来是没有非常完善的，但是很多的Ajax框架，如Ext、GWT、Tibco GI以及服务端框架Struts2、JSF等，都在以自己的方式实现着。关于这个方面的探讨我打算放到下一个系列《基于MDA的企业应用RIA解决方案》里面讨论，不在这里多费口舌了。
技术上是可行的，而如果又一个非常稳定和成熟的平台支持的话，在工程开发上也是可行的，那么这个平台怎样才算是稳定和成熟的呢?本系列讨论的就是其中的一部分，客户端的数据处理。
三、定义、缩略语
下面是本文中使用的技术名词的定义以及缩略语简介。
RIA：Rich Internet Application的缩写。RIA是拥有传统本地应用的功能和效果的Web应用。RIA一般把UI相关的处理交给了Web客户端，但是大量的数据(包括应用的状态、数据等)还是交给服务端处理
Ajax：又写为AJAX，是"Asynchronous JavaScript and XML"的缩写。是一种使用浏览器技术进行RIA开发的技术
ECMA Script：由European Computer Manufacturers Association(欧洲计算机制造商协会)维护的一个脚本语言标准。当前最通行的版本是ECMA-262 Edition 3，通常也被称为JavaScript 1.5
dojo：由dojo foundation管理的一个开源JavaScript框架。提供了很好的JavaScript扩展，目前被IBM和Sun等大公司支持和使用
Json： JavaScript Object Notation的缩写。它是一种纯文本的数据对象传输协议，在Ajax的应用中被广泛采用
CRUD：Create(创建)、Retrieve(获取)、Update(更新)和Delete(删除)这四种简单的数据操作的缩写
Form：本文中的Form指的是经过Ajax扩展的简单的HTML电子表单。表单内部可以拥有很多如ComboBox、TextBox等构件。一般来说，一个表单对应着一个业务的数据对象
Tree：树形显示结构化数据的构件，由于数据是高度结构化的，往往可以采用懒加载等技术来提高性能
Grid：以表格形式显示和编辑数据的UI构件。一般分为表头(标题栏)、表身(数据列表)和表尾(合计、状态显示等)三个部分。其中，表头可以是复合的表头，而表身可以是复合的格式(Tree、Grid、ComboBox、CheckBox等)。一个Grid可以有一个复杂的Grid定义
Enhanced Grid：下面简称为EGrid，是Grid的扩展。在Grid的功能基础之上提供了数据获取和数据持久化的能力，可以大大的减少开发应用的时间(Ext中的Grid可以认为是一个简化了的EGrid)
CodeList：代码表，一般用在下拉列表数据处，在系统的实现中，由于性能以及标准的要求，下拉列表一般都是采用代码保存数据，但是用户在填写表单的时候需要看到正常的文字而不是代码，这就需要系统通过CodeList进行文字和代码的转换
LRU：Least Recent Used的缩写，是一种简单的缓存策略，如果缓存已满，那么就释放最近最少使用的那个缓存数据
REST：是REpresentational State Transfer的缩写，是一种基于轻量级WebService协议
四、客户端数据处理的技术场景
在本部分里将会针对下面六个分类对客户端数据处理的技术场景进行概述
数据绑定(Data Binding)
数据变更追踪(Data Change Tracking)
数据访问(Data Access)
数据缓存(Data Caching)
数据查询(Data Query)
数据处理(Data Processing)
4.1 数据绑定(Data Binding)
概念：
以非常简单的声明方式实现Form、Grid这种数据填写、修改构件与数据之间的对应关系。
场景：
Form绑定：把一个Form与一个数据对象通过声明的方式绑定，使得Form的修改直接可以体现在数据对象中，而数据对象的修改也可以马上由Form体现出来
Grid绑定：把一个Grid和一个数据对象集合通过声明或者设置数据源的方式绑定，使得在Grid上的写操作都可以体现在数据对象集合中，而数据对象集合的操作也可以马上由Grid构件体现出来
Tree绑定：由于Tree的特殊性，与其说Tree与一个数据对象集合绑定，不如说Tree使用了一个可以根据查询提供数据的数据来源更合适。当然，由于Tree有可能被可视化的修改(如组织机构管理)，所以这个数据来源必须支持对数据的写操作
其它：如菜单的绑定等，相对于上述三个都属于非常用的绑定，而且如果上述绑定能够实现，那么其他的绑定也可以采用同样的技术实现
4.2 数据变更追踪(Data Change Tracking)
概念：
对数据的整个生命周期进行追踪。主要的目的就是可以通过记录看出数据做了哪些改变，然后根据这些改变做出相应的处理，其使用场景有Grid的变更提示、Form修改的追踪等。
场景：
Grid变更提示：在Grid中以明显的方式提示用户做了哪些修改
数据集合变更追踪：根据变更的效果，可以有选择的发送合适的数据给服务端进行处理
Form修改的追踪：为用户在提交Form时提示用户哪些重要的字段进行了修改提供支持
4.3 数据访问(Data Access)
概念：
服务端与客户端数据传输的格式未必相同，而且数据对象属性的类型等信息也需要一些Meta Data API来进行支持。所以，抽象出一个抽象的拥有Meta Data的数据访问层是有意义的。
场景：
数据对象元数据信息访问：可以通过这些元数据信息了解数据对象的各个属性以及对应的数据类型(这一点对于Json格式的数据传输尤其重要，因为Json规范里面没有DateTime类型)
数据写操作的统一事件定义：通过Data Access API来访问数据，所有的写操作都会有统一的事件定义，在JavaScript 1.5中，普通的JavaScript对象是做不到的
统一的数据读取方式：不管数据是XML格式的还是Json格式的，访问数据的方式都是统一的
4.4 数据缓存(Data Caching)
概念：
数据缓存是指把获得的数据以一定的策略缓存起来，以备使用的技术。Cache是客户端数据处理中涉及到功能和性能的重要部分，原因请见下面的场景
场景：
离线运行的CodeList：系统如果需要离线运行，那么CodeList肯定需要客户端缓存
离线表单填写：如果允许用户离线填写表单，那么需要采用客户端缓存策略保存用户的数据
性能考虑：向服务端发请求，服务端查询并返回属于非常耗费资源和时间的操作，所以对于服务端的数据，客户端应该有一定的缓存以及同步策略
4.5 数据查询(Data Query)
概念：
数据查询的概念非常简单，根据用户的查询条件向服务端发送查询请求，得到服务端返回的数据对象集合。
但由于数据查询是系统中最常用的功能，所以，数据查询需要非常强大的功能。简单列举如下。
场景：
样本查询：给出一个样本，比如{age : 20, gender : 'male'}，返回所有符合样本的结果
模糊查询：用户可以提供非明确的查询参数(如李??，查询所有姓李的，名字为三个字的人)，返回结果供用户进一步的筛选
Range查询：根据Start Index和Count返回整个大数据集中的一部分，一般用在分页查询处理方面，当然也可以用在其他的需要整个数据集的一部分的地方
逻辑查询：采用逻辑操作对数据进行过滤查询，比如(employee中所有满足age < 40 && age >30 && gender = ‘male’ && married条件的员工——年龄大于30且小于40的已婚男员工)，实际上上面所说的查询都可以以某种方式归为逻辑查询的一种，之所以明确的提出来，是因为查询的语法有可能有所不同，并且有些构件或者服务会对某些查询有特别的需求或者加强的支持以简化开发的难度，提高开发的效率
自定义查询：根据用户的需要可以对上面的查询进行有机地结合
4.6 数据处理(Data Processing)
概念：
在数据查询、显示、修改和持久化的过程中，用户有可能还需要做一些监控，以及一些自定义的操作，如过滤、排序等。这就需要一套数据处理的事件以及数据处理的方法。这些统一归到数据处理用例中。列举如下。
场景：
数据处理事件：数据的查询以及持久化过程中的事件
数据过滤：通过数据过滤(查询前、查询后)可以满足权限控制等功能的要求
排序：可以对数据进行自定义的排序(查询、查询结果
五、小结
客户端的数据处理能力是客户端最主要的基础能力，它直接影响到了应用服务器的负荷以及用户UI响应的速度和效率。所以，客户端的数据处理支持是一个RIA平台非常重要的考核点。可以上面的六类场景去考核各种RIA平台，同时，它们也为我提出我的RIA客户端数据处理解决方案提供了基础的用例。
