為什麼選擇LiteDB
之前做uwp的時候有做過一個植物圖鑑,當時圖片使用的是線上圖片,所以圖片很多也並沒有什麼體驗上的差別,但是直到有一天別人的網站掛掉了,圖片訪問不到了,當時想訪問不到也沒啥,反正圖片都被我爬到本地了,於是就把圖片統統放在Assets目錄裡,把url改了下就啟動了。
可是事實很尷尬,也不知道uwp是怎麼訪問Assets目錄的檔案,總之啟動很卡,彷彿每次啟動都會遍歷一遍Assets的檔案一樣,所以我天真的感覺改個目錄就行的方式不行了,PS(當時使用的是sqlite加ef儲存的資料),顯然舊方法不行就要想新方法了。
查了下文件,sqlite也能儲存檔案,為什麼我沒選擇繼續用sqlite呢?主要是因為ef的最新版本不支援uwp了,舊版本我也不想用了,剛好在很久的時候也讀到了h大佬的一篇講LiteDB的文章,於是腦子裡就出現了LiteDB這個選項。
強烈建議先看H佬的文章
另外一點平時公司使用的資料庫也是MongoDB,在我看了LiteDB的api之後,發現它的風格和MongoDB的api風格很像,剛好使用起來也比較方便。廢話少說,先來張圖鑑圖片看看效果。
WinUI使用LiteDB的上手體驗
首先我們先建立一個WinUI的專案,然後安裝名稱為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算是繼承了uwp的衣缽。
XAML程式碼如圖
WinUI可以期待些什麼
demo我使用的是WinUI 1.0的版本,目前1.1版本正在預覽,新增很多新特性,如下圖:
整體可以期待的是winui替代uwp的那一天吧,不過目前看來uwp還是可以很長命的,因為winui目前好像還不支援xbox,而且c# .net版本的winui目前啟動速度也是有點慢。目前如果開發的應用不復雜,替代wpf還是可以的。
推薦的專案地址如下: