【UWP】使用 LiteDB 存储数据

序言：

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

场景分析：

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

{
    "id": 1,
    "name": "Justin Liu",
    "gender": 2,
    "location": {
        "name": "Melbourne",
        "name_cn": "墨尔本"
    }
}

又或者做一个 RSS 阅读器，弄个后台服务提前先把数据拉下来，那肯定也要存放起来吧。这相当于要把一个以时间排序为依据的列表进行持久化。

ApplicationData Settings 方案

在以上两种场合，用 ApplicationData Settings 解决起来可能是比较快速的。以第一种情况来说，又可以细分两种存储方案。

A 方案，分字段存放：

ApplicationData.Current.LocalSettings.Values["user.id"] = user.Id;
ApplicationData.Current.LocalSettings.Values["user.name"] = user.Name;
ApplicationData.Current.LocalSettings.Values["user.gender"] = user.Gender;
ApplicationData.Current.LocalSettings.Values["user.location.name"] = user.Location.Name;
ApplicationData.Current.LocalSettings.Values["user.location.name_cn"] = user.Location.NameCn;

当然调用 ApplicationData.Current.LocalSettings.CreateContainer 拿个 Container 来存也是可以。（或者说这样更好一点）

这样存储的话，可以按需更新，也可以按需加载，例如我只需要用户的名字那就只加载名字好了。

但这方案缺点也不少，一个是假如上面的 Gender 是一个枚举，那这段代码就炸了。ApplicationData Settings 是不能直接存储枚举类型的，需要处理一下（一般转数值存，不建议转字符串存）。另一个如果字段多的话，代码行数也跟着变多，就很容易就会写错。但实际上如果字段少的话，这方案是相当合适的。

B 方案，序列化存放：

ApplicationData.Current.LocalSettings.Values["user"] = JsonConvert.SerializeObject(user);

说起序列化，那第一时间肯定是想到 JSON 了。这方案解决了 A 方案的痛点，但按需加载、按需更新就无法实现了。这个方案胜在泛用，包括 Windows Community Toolkit 也是这么做的。但在我看来，这个方案只满足了需求，但不够优秀。一是依赖了 JSON.net（或是别的 JSON 库），另一个是序列化和反序列化的性能，特别是对象较大的时候。

小结：

这仅仅只是考虑到上面 user 这种结构的存放，如果是 rss 那种的结构，存放的话， A 方案几乎做不了，B 方案倒是能做。但假如做个查询（例如查询某一天时间范围内的），ApplicationData Settings 方案是解决不了的（当然你说全部加载到内存再查询也行，但这就跟用 EF 全部加载出来再分页一样搞笑）。

Sqlite 方案

Sqlite 方案其实也可以细分两种，一种是直接撸 sql，另一种是用 ef core 这种 orm 框架。撸 sql 这种方案说实话我是没实行过，因为相当的不 awesome，我自己也很多年没写过一行 sql 了（虽然我平时上班是干后端工作的）。这里主要说说 ef core 的方案。

新建一个 .net standard 的项目：

Article.cs 如下：

public class Article
{
    public int Id { get; set; }

    public string Title { get; set; }

    public string Content { get; set; }

    public DateTime PublishTime { get; set; }
}

ApplicationDbContext.cs 如下：

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext()
    {
    }

    public DbSet<Article> Articles { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        base.OnConfiguring(optionsBuilder);

        optionsBuilder.UseSqlite("Data Source=articles.db");
    }
}

并且项目引用 Microsoft.EntityFrameworkCore.Sqlite 包，注意是用 2.2.6 版本的，3.x 的 UWP 用会炸！

然后创建数据库迁移：

接下来 UWP 项目引用该 .net standard 库，修改 App.xaml.cs 的代码：

public App()
{
    using (var context = new ApplicationDbContext())
    {
        context.Database.Migrate();
    }

    this.InitializeComponent();
    this.Suspending += OnSuspending;
}

这样启动程序的时候就会执行数据库迁移了，接下来程序代码里就可以使用了。

因为主题并不是 Sqlite，这里我就仅仅以 demo 级的态度代码来举例子，而且园子里也有大牛写过相关更详细的博文。

小结：

Sqlite 方案看似很好，但我认为缺点也是有的。一个是该方案太重了，关系型数据库意味着就是有数据表，像我只是要存个 user 的信息的话，come on，能 easy 一点吗？另一个就是 ef core 对 UWP 的支持度，上面我也说了，3.x 的是会炸掉的。PS 一句，微软对 UWP 目前不是很上心，System.Text.Json 这个包，4.7.0 版本在 UWP 上要用就得写 rd.xml，但 4.6.0 就不需要。总结一点，Sqlite 方案就是把牛刀，而我们目前是要杀鸡。

分析：

那有没有介于 ApplicationData Settings 和 Sqlite 之间的方案呢？Sqlite 是关系型数据库，嗯，意味着 sql。说到 sql，就想到 nosql，就想到 MongoDb、Redis 这些玩意。事实上，由于这些 nosql 数据库都是 schema less 的，也就是不存在表结构，增删字段就没有说改动表结构这么一说，因此是相当适合用在一些非关键性数据的存储当中的。但是 MongoDb、Redis 这些玩意都是需要一个 server 端，而 UWP 肯定不可能带个 server 的，那么有没有类似于 Sqlite 这种单文件无 server 的，而且 UWP 能用的呢，当然最好的话还是用 .net 开发的。我找了一下，还真被我找着了，接下来就是本文的主角 —— LiteDB。

正文：

LiteDB 官方主页：https://www.litedb.org/

Github：https://github.com/mbdavid/LiteDB

在我们的 UWP 项目中添加 LiteDB 的引用。（注意本文使用 5.0.0-rc 版本，因为需要对应下文的 LiteDB Studio 使用）

以插入数据为例：

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

    var article = new Article
    {
        Title = "test title",
        Content = "test content",
        PublishTime = DateTime.Now
    };

    articles.Insert(article);
}

数据库路径需要设定一下，放在 UWP 的用户数据文件夹下面。否则会放到 Appx 文件夹，而这个路径是没有写入权限的。

db.GetCollection<Article>() 这一句相当于在该数据库中创建了一个文档（假如不存在），用 Sqlite 的概念来说就是创建了一个表。名字就叫 Article，当然也可以通过该方法的重载来设置名字。Id 我们不需要进行设定，这个跟 EF 是一样的，默认是会自动递增的。然后我们来看看我们的数据是否插入成功。下载 LiteDB Studio（我下载的是 0.9 版本）：

https://github.com/mbdavid/LiteDB.Studio/releases

下载之后打开我们的数据库，数据库的路径可以给上面代码打个断点拿到 dbPath 的值。

打开的话是这个样子：

然后右键我们的 Article 选择 Query

可以看见出现了类似于我们熟悉的 sql 语句，然后点击 Run 按钮。

可见我们刚才插入进去的数据出现了。

回到需求这边来，假设我们这个 Article 类某天多了个字段，例如文章作者。修改 Article.cs：

public class Article
{
    public int Id { get; set; }

    public string Title { get; set; }

    public string Content { get; set; }

    public string Owner { get; set; }

    public DateTime PublishTime { get; set; }
}

修改我们的插入数据代码：

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

    var article = new Article
    {
        Title = "test title",
        Content = "test content",
        Owner = "Justin Liu",
        PublishTime = DateTime.Now
    };

    articles.Insert(article);
}

再次看看我们的 LiteDB Studio。

可见数据是已经插入进去了，没有任何的数据库表迁移，相当优雅而且 easy。

要做查询的话也简单：

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 数据库的话，因为没有迁移，所以也不存在丢失数据的问题了。

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