原文:

序言：

在 UWP 中，常见的存储数据方式基本上就两种。第一种方案是 UWP 框架提供的 ApplicationData Settings 这一系列的方法，适用于存放比较轻量的数据，例如存个 Boolean 类型的设置项这种是最适合不过的了。另一种方案是用 Sqlite 这种数据库，适合存放数据量大或者结构复杂，又或者需要根据条件查询的场合，例如开发个宝可梦数据查询，或者 Jav 图书馆（咳咳）。

场景分析：

在某些场合，我们很可能是要持久化一个复杂的对象的，例如通过 OAuth 授权成功获取到的用户信息，有可能就类似下面的结构：

var dbPath = Path.Combine(ApplicationData.Current.LocalFolder.Path, "MyArticles.db");
using (var db = new LiteDatabase(dbPath))
{
    var articles = db.GetCollection<Article>();

    var list = articles
        .Find(temp => temp.PublishTime >= DateTime.Parse("2020-01-20 13:00:00"))
        .ToList();
}

当然还有更多用法，这里就不再介绍了，各位看官可以去看 LiteDB 官方的文档，而且这玩意我觉得算是个较为成熟的东西了。

总结：

本文我觉得更偏向于与各位看官交流经验吧，本文中 ApplicationData Settings 的 A、B 方案其实我项目也都有在使用。特别 A 方案，加载数据的时候需要特别严谨的逻辑，例如其中一个字段没有值该如何处理这种。B 方案则简单 catch 个 JsonSerializationException 一般就没问题了，有时候偷个懒还是挺方便的。而 Sqlite 的方案，说句实话，我目前并没有在项目中用到（之前有一个但后来弃坑了，而且是 DbFirst 而不是本文 CodeFirst 的方式）。所以 Sqlite 方案，我在写本文的时候才发现最新的 3.1.1（理论上 3.x 的都这样）在 UWP 上压根就用不了。

对于本文的主角，LiteDB。我是持乐观态度的（虽然我还没在我项目中用到，下个项目想个办法用上^-^）。一般来说，客户端存放的数据重要性肯定是不高的，重要的肯定都是存到服务端去了。也就是说，客户端的数据更多情况是起到一种缓存一样的作用。例如上面的，假如 user 没数据了，那让用户重新授权一次就好了，这没啥的。对于这些场景来说，关系型数据库就太重了，而且数据库迁移是有可能丢失数据的（这个 ef 创建迁移的时候有提示，但实际上代码肯定要去留意的）。在服务端，如果某行数据缺失字段的话，连上数据库手动补一下就好了。但假如这数据库是在客户机器上，那就头大了。用 LiteDB 这种 nosql 数据库的话，因为没有迁移，所以也不存在丢失数据的问题了。

最后再说一句，本文只提供了思路，但实际还是要看场景来分析。反正不管黑猫还是白猫，抓到老鼠就是好猫嘛。