移动开发中的数据持久化模型设计（一）--数据唯一性

前言

算法导论里说 Program = Data + Algorithm

对于移动开发而言 Application = Data + UI

作为前端开发，我们的日常工作绝大部分工作都在同数据和UI界面打交道，而界面更是依赖于数据而存在。

这时候一个高效的数据持久化模型，能够帮助我们从加载、缓存和管理数据的繁杂任务中剥离出来，将精力专注到界面交互上。

移动开发的特殊性

我们先看看移动开发中数据到界面的加载逻辑。



如上图所示，移动应用先从后端获取数据，进而才在界面中进行加载渲染。

对于移动应用而言，如果在界面切换的过程中频繁的进行数据请求，在开始请求数据到数据请求完成的过程中，用户界面无法进行正常显示，势必会影响用户的正常使用。因此我们应该尽可能复用历史请求数据，减少不必要的数据请求。

下面我们会使用一个类似微博朋友圈这样的场景来简单陈述一下。

数据的一致性

朋友圈的数据类图如下:



每一条数据都会有一个唯一id进行对应。

我们应该保证这种具有唯一id的数据在客户端也具有*唯一性*，也就是说当我们在本地对指定id的数据进行操作时，与该数据拥有同一id的其他数据也应该被同步操作行为。

让每一条数据唯一

为了实现上面所说的这种数据同步，最简单的方法就是令每个数据实例对象唯一。

例如我们现在有3条Trend，且都是同一个User所发，那么在这3条Trend中的User都应该指向同一个User对象。这样如果我们对这个User对象中数据进行操作，那么3条Trend中的User对象自然也会发生改变(毕竟是同一个对象)。



为了达到数据唯一的效果，我们应该在对数据进行实例化的时候，先从DataRepo获取可能存在的实例对象，如果发现存在则复用之前已经实例的对象，否则才构造一个新的对象，并把这个对象缓存到DataRepo中。

举个栗子，我们通常会使用Gson来实例化json对象，这时候我们就可以针对我们希望进行唯一化的数据类进行注册TypeAdapter，当Gson进行数据实例化的时候，就会通过我们自己的接口去拦截对象实例化的过程，从而实现对象唯一。

通过上面的手段，我们实现了数据的唯一性，一旦我们对数据进行操作，就会立刻同步到同一个数据去。但与此同时，我们也需要避免数据受到脏数据的污染。

避免返回脏数据

很多时候，由于接口设计的原因，可能不同接口会返回不同的数据。

例如在Trend中的User对象中，我们可能只需要用户的头像和昵称信息，因此服务器在获取Trend信息的数据中，只会包含User的头像和昵称，而忽略掉其他相关属性。只有当我们去请求用户的详细信息时，才会将其他属性返回过来。

我们在上面说过，为了维护数据的唯一性，我们不论是从Trend中获取的User对象，还是通过请求详细信息中的User对象，他们其实都是同一个对象。

如果我们在已经获取了Trend中的User对象的基础上，获取到了User详细信息，然后进行数据合并，自然能够保证User对象的数据完全正确，但是如果是我们在已经获取到了详细的用户信息，这时候我们又获取到了Trend的User信息，这时候User信息偏少，如果我们将所有属性进行重新赋值，则会导致赋值前完整的数据信息丢失。

但我们在实例化对象信息的时候，其实并不能知道哪一个数据是正确的，是完整的，所以我们只能够信任最后一条数据。如果恰好最后一条数据是不完整的，则之前的数据会被污染掉。

为了解决这个问题，我们只能让服务器不要返回脏数据。例如我们只需要User的头像和昵称，那么在返回的数据中只需要用户的头像和昵称字段，其他字段直接忽略掉。这样我们在实例化对象的时候，只对当前存在的字段进行赋值，从而避免脏数据污染。

后续

先简单介绍一下如何实现数据的唯一化和他的作用，在之后的文章中，将进一步探讨如何选择刷新数据的时机。