為什麼選擇LiteDB 之前做uwp的時候有做過一個植物圖鑒，當時圖片使用的是線上圖片，所以圖片很多也並沒有什麼體驗上的差別，但是直到有一天別人的網站掛掉了，圖片訪問不到了，當時想訪問不到也沒啥，反正圖片都被我爬到本地了，於是就把圖片統統放在Assets目錄里，把url改了下就啟動了。 可是事實很尷 ...
為什麼選擇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還是可以的。
推薦的項目地址如下：
LiteDB - A .NET NoSQL Document Store in a single data file
