大音希声大象无形

作为一个软件开发人员。电子书、文档基本上是每天都要看的。手头都会有一些电子文档或者电子书。

管理好这些电子书，却远比想象得要复杂得多。为什么呢？因为它涉及到了书。它不仅仅是简单的文档管理，而是个人的学习资料、知识管理。我们来分析一下吧。

一般而言，根据个人的查看方式，电子书可以分成这么几类。

1、有些书下载了，却未必会看

由于下载的方便性，以及电子文档的特殊性，使人容易忽略电子书的信息量。

很多电子书，同样的信息量，换成纸质文档，书本的大小就会让很多人望而却步。但是，变成电子文档后，使很多人忘记了这一点。

只是觉得可能会有用，就下载下来了。其实根本就不会去看。又舍不得删掉，成了电子垃圾（不要跟我说有什么收藏价值，那是自己安慰自己罢了，没人看的电子书就是电子垃圾）。

2、有些书需要反复的看

有一些书（比如设计模式），是典型的手册型书。你会发现，你可能会经常性的

而且，往往会有一些书值得反复阅读，或者用来当作手册来时常查阅。

3、有些书看一遍就可以扔掉了

重构就是这种类型，不是说这本书不好。而是你看完了之后，你就理解了它的思想。在日常的工作中，你会经常的遇到这些问题，使用这些方法。你不会忘记它的教诲了，因为它已经成为了你工作的一部分了。这种书可以比喻成电器的说明书，一般你只在刚刚买到的时候看一下，之后就扔到一边去了。

还可以从另外一个方面来看，就是信息量的方面，电子书可以分成下面几类

1、大信息量型

有的书的内容有很大的信息量（比如存粹理性批判），需要采用精读甚至反复读的方式来进行理解和消化。往往每天只能读和消化几页（有的时候几页就不错了）。

2、中等信息量型

3、低信息量型

比较差的技术类书籍属于此等类型。篇幅很大，但是有价值的内容乏善可陈。或者供娱乐使用的书。比如某些网络小说。

通过这两个分类，可以通过一个表格把电子书分类。

大|经典教材、经典难懂的书

中|手册普通的书别人推荐的书

小|喜欢的消遣骗人的书

没把大部头加上去，因为大部头的定义不是很清晰。

好了，总结一下。

我们可以按照书的信息量和自己是否看把自己的书分成下面几个分类：

经典、手册、喜欢的、教材、普通的书、消遣、难懂的书、别人推荐的书、骗人的书

PS：当然，这这是我的分类。你可以有其他更好的分类方式。

这个blog已经荒废将近一年了，久也不写，自然有很多的理由，但更多的怕是懒吧。不说闲话了，转入正题。

先说有没有必要，答案是肯定的。B/S被广为诟病的一个问题就是降低了最终用户的操作效率，以我的经验来说，用户虽然普遍的感到基于浏览器的界面要漂亮得多，用鼠标操作也很直观，但是却实在比以前的界面复杂而且操作困难。而且每次页面提交后的等待也实在是对工作效率的一个降低。当然，我这里也没有必要意义列举B/S在客户端的缺点，实际上这个问题是被广泛认同的。

再说可行性，可行性分为两种：技术上的可行性以及工程开发上的可行性。

技术上的可行性就无须验证了，GoogleReader、Gmail、GoogleDocs的稳定运行都是非常好的证明。

这就需要一个非常稳定的平台来进行支持，而且由于工程开发的特殊性，最好还要有可视化的开发和调试环境才更有说服力。目前看来是没有非常完善的，但是很多的Ajax框架，如Ext、GWT、TibcoGI以及服务端框架Struts2、JSF等，都在以自己的方式实现着。关于这个方面的探讨我打算放到下一个系列《基于MDA的企业应用RIA解决方案》里面讨论，不在这里多费口舌了。

技术上是可行的，而如果又一个非常稳定和成熟的平台支持的话，在工程开发上也是可行的，那么这个平台怎样才算是稳定和成熟的呢？本系列讨论的就是其中的一部分，客户端的数据处理。

概念：

场景：

对数据的整个生命周期进行追踪。主要的目的就是可以通过记录看出数据做了哪些改变，然后根据这些改变做出相应的处理，其使用场景有Grid的变更提示、Form修改的追踪等。

服务端与客户端数据传输的格式未必相同，而且数据对象属性的类型等信息也需要一些MetaDataAPI来进行支持。所以，抽象出一个抽象的拥有MetaData的数据访问层是有意义的。

数据缓存是指把获得的数据以一定的策略缓存起来，以备使用的技术。Cache是客户端数据处理中涉及到功能和性能的重要部分，原因请见下面的场景

数据查询的概念非常简单，根据用户的查询条件向服务端发送查询请求，得到服务端返回的数据对象集合。

但由于数据查询是系统中最常用的功能，所以，数据查询需要非常强大的功能。简单列举如下。

在数据查询、显示、修改和持久化的过程中，用户有可能还需要做一些监控，以及一些自定义的操作，如过滤、排序等。这就需要一套数据处理的事件以及数据处理的方法。这些统一归到数据处理用例中。列举如下。