- A+
为什么选择LiteDB
之前做uwp的时候有做过一个植物图鉴,当时图片使用的是在线图片,所以图片很多也并没有什么体验上的差别,但是直到有一天别人的网站挂掉了,图片访问不到了,当时想访问不到也没啥,反正图片都被我爬到本地了,于是就把图片统统放在Assets目录里,把url改了下就启动了。
可是事实很尴尬,也不知道uwp是怎么访问Assets目录的文件,总之启动很卡,仿佛每次启动都会遍历一遍Assets的文件一样,所以我天真的感觉改个目录就行的方式不行了,PS(当时使用的是sqlite加ef存储的数据),显然旧方法不行就要想新方法了。
查了下文档,sqlite也能存储文件,为什么我没选择继续用sqlite呢?主要是因为ef的最新版本不支持uwp了,旧版本我也不想用了,刚好在很久的时候也读到了h大佬的一篇讲LiteDB的文章,于是脑子里就出现了LiteDB这个选项。
强烈建议先看H佬的文章
另外一点平时公司使用的数据库也是MongoDB,在我看了LiteDB的api之后,发现它的风格和MongoDB的api风格很像,刚好使用起来也比较方便。废话少说,先来张图鉴图片看看效果。
WinUI(WindowsAppSDK)使用LiteDB的上手体验
首先我们先创建一个WinUI(WindowsAppSDK)的项目,然后安装名称为LiteDB的nuget包,如下图。
项目本身没什么特别的,主要是采用CommunityToolkit控件库里的AdaptiveGridView控件结合MVVM进行数据的加载展示。
AdaptiveGridView绑定ViewModel里的属性,属性通过CommunityToolkit提供的增量加载集合IncrementalLoadingCollection进行服务的绑定,主要逻辑在PersonalInfoSource实现。
通过针对LiteDB数据操作的封装,我们就可以在PersonalInfoSource服务里调用IPersonalInfoRepository仓储接口,对应的实现就是封装了LiteDB的增删改查,包含图片文件的存储。
主要涉及到LiteDatabase类的GetCollection方法,不同的Collection我们可以认为是不同的表,针对某个Collection的插入读取就相当于针对单表的插入和读取。
图片文件的存储涉及到GetStorage方法,这个我们可以根据需要命名,如上图我们可以通过Upload方法将图片存储到数据库文件。
图上的方法把数据存储成功了,我们读取的时候操作也类似,通过Collection将数据读出,然后针对图片文件读取成流,放到对象里。
public Task<IReadOnlyCollection<PersonalInfo>> GetListAsync( int pageIndex, int pageSize, CancellationToken cancellationToken = default) { var query = _liteDatabase.GetCollection<PersonalInfo>().Query(); var list = query .OrderByDescending(p => p.Name) .Skip((pageIndex) * pageSize) .Limit(pageSize) .ToList(); if (list != null && list.Count > 0) { var fs = _liteDatabase.GetStorage<string>("dataFiles", "dataChunks"); foreach (var item in list) { if (fs.Exists($"$/Data/{item.AvatarName}")) { LiteFileInfo<string> file = fs.FindById($"$/Data/{item.AvatarName}"); Stream stream = new MemoryStream(); fs.Download(file.Id, stream); stream.Seek(0, SeekOrigin.Begin); item.AvatarStream = stream; } } } return Task.FromResult((IReadOnlyCollection<PersonalInfo>)list); }
流的读取主要涉及到Download方法,针对流可以执行stream.Seek(0, SeekOrigin.Begin);
这部分的代码我参考了一个uwp的demo地址如下:
现在我们获取到了列表信息和图片流,只要在展示的时候处理下,就可以绑定到AdaptiveGridView,将流转换成BitmapImage就可以展示到界面上了。
看到这里整体的使用过程就算是结束了,感觉上和uwp使用没什么区别,毕竟WinUI(WindowsAppSDK)算是继承了uwp的衣钵。
XAML代码如图
WinUI(WindowsAppSDK)可以期待些什么
demo我使用的是WinUI 1.0的版本,目前1.1版本正在预览,添加很多新特性,如下图:
整体可以期待的是winui(WindowsAppSDK)替代uwp的那一天吧,不过目前看来uwp还是可以很长命的,因为winui(WindowsAppSDK)目前好像还不支持xbox,而且c# .net版本的winui(WindowsAppSDK)目前启动速度也是有点慢。目前如果开发的应用不复杂,替代wpf还是可以的。
推荐的项目地址如下: