数据持久层框架备忘录（手机平台）

数据持久层框架备忘录（手机平台）

 

作为智能手机，无论是在MMI应用程序里，还是在PIM应用程序中，数据的查询、排序、存储功能的代码都占很大比例。所以说，数据持久层框架是一个基础性的架构，它的设计好坏，直接影响整个平台的品质。在这方面，我们从一开始就很慎重。

 

尽管本文中的基本观点都是我提出，然后和大家一起讨论细化的，但毕竟是大家的劳动成果，我没有权力写出来与别人分享。问题在于，我们几个人都可以自称是嵌入式方面高手，而在数据库方面则是门外汉，除了本人N年前做一段时间数据库编程外，其他人都没有数据库方面相关的经验。

 

而这几年来，数据库应用方面的技术又是日新月异，一些先进的技术，除了对于一些像我这样的井底之蛙外，已经不是什么秘密了。呵，这里写出来，也算不上是泄露机密吧。一方面是做个备忘，另外一方面也希望有高手能指出其中谬误。或许在高手眼中，我们的方法完全是错误的，也是难说的。

 

准则一：把业务逻辑和数据持久层分开。

这已经是业界的惯例了，原因无需要多说。

 

准则二：以面向对象的方式访问数据，而不是面向表的方式访问数据。

我们整个平台都采用面向对象的方法开发，自然的要采用面向对象的方式访问数据。这样让数据及数据的存储与上层业务逻辑无缝的结合起来。

 

准则三：把数据对象与数据对象的持久化功能分开。

数据对象仅仅代表一条记录，可以存取其中的每一个字段的信息，包括值、名称和类型，也可以遍历其中所有字段。

 

具体化数据对象提供更容易使用的包装函数，它们仅仅是数据对象提供的函数进行包装而已。比如名片，提供诸如GetPhoneNo之类的函数去包装数据对象的GetField函数，调用者使用具体化数据对象更方便。

 

数据持久化对象负责检查、更新、删除、新增记录，唯它与数据库有关联。

 

具体化数据持久化对象与具体化数据对象一样，只是包装出更易使用的函数。

 

准则四：查询条件不依赖于后端数据存储和访问方式。

对于手机平台而言，后端的数据库未必是按SQL语句访问的，故不能限制于SQL的条件方式。所以我们设计一个独立的类来表示条件，它实际上是一个条件表达式，按照树结构组织。

      

这里可以使用visitor模式，根据不同的情况实现不同的visitor去产生目标条件格式，目前只实现产生SQL语句条件的visitor。

 

准则五：查询分为同步和异步两种方式，但对调用者的使用没有影响。

无论是同步方式还是异步方式查询，用户得到的都是一个数据对象集。但数据对象集是一个抽象的接口，对用户来说，它只是一个数据对象容器，可以取得出其中任何一个数据对象。

 

但实现分为两种，即同步数据对象集和异步数据对象集两种，对于前者，它完全等同于一个容器，而后者，对于数据的查询操作延迟到使用对象时才查询，相当于一个代理，也相当于一个缓存。

 

准则六：考虑资源限制。

手机平台的内存和CPU等资源都很有限，在设计时我们要考虑这些资源限制。主要解决方法就是对于大量数据的查询，如名片列表显示，采用异步对象集。可以通过参数控制，先预取一部分数据，其它数据直到真正使用时，才从数据库中取出，这样不仅可以减少等待时间，也可以避免同时使用大量内存。而且对于调用者来说，是完全透明的。

 

准则七：方便的与控件绑定。

在手机平台中，对于大多数应用程序，对记录的操作无非三种：列表显示全部或部分记录、显示记录的详细信息、编辑记录。这些界面大同小异，对不同的应用程序各写一套，重复代码太多，而容易出错。

 

让数据对象与控件绑定起来是一种比较好的方法，在Window一向习惯这么做。我们设计时要考虑这一点，鉴于前面所说的，这一点非常容易做到，因为我们的数据对象是抽象的，控件不需要知道具体化的数据对象，就可以方便存取数据对象的字段。