《在ASP.NET Core中使用Apworks快速開發(fā)數(shù)據(jù)服務(wù)》一文中，我介紹了如何使用Apworks框架的數(shù)據(jù)服務(wù)來快速構(gòu)建用于查詢和管理數(shù)據(jù)模型的RESTful API，通過該文的介紹，你會(huì)看到，使用Apworks框架開發(fā)數(shù)據(jù)服務(wù)是何等簡(jiǎn)單快捷，提供的功能也非常多，比如對(duì)Hypermedia的支持，以及提供豐富的異常信息和調(diào)用棧信息。另外，Apworks數(shù)據(jù)服務(wù)可以支持各種類型的倉儲(chǔ)（Repository）實(shí)現(xiàn)，在該文的案例中，我使用了MongoDB作為倉儲(chǔ)的實(shí)現(xiàn)，這是為了快速方便地演示數(shù)據(jù)服務(wù)的搭建過程。如果你所使用的是關(guān)系型數(shù)據(jù)庫，也沒有關(guān)系（意思是不要緊，不是說數(shù)據(jù)沒有關(guān)系。。。-_-!!!），基于Entity Framework Core的倉儲(chǔ)實(shí)現(xiàn)能夠滿足你的需求。
需要注意的一個(gè)問題
在以前老版本的Apworks中，倉儲(chǔ)的接口是支持饑餓加載的，也就是說，在延遲加載被啟用的時(shí)候，倉儲(chǔ)允許通過顯式指定一系列的對(duì)象屬性，當(dāng)主對(duì)象被返回時(shí)，這些屬性所指向的子對(duì)象也會(huì)同時(shí)返回。這樣的設(shè)計(jì)在當(dāng)時(shí)的場(chǎng)景下是合理的，因?yàn)槭欠裥枰虞d某些屬性是可以在程序中指定的，對(duì)于類似MongoDB的倉儲(chǔ)實(shí)現(xiàn)，它沒有延遲加載的概念，因此可以忽略這個(gè)參數(shù)。在Apworks數(shù)據(jù)服務(wù)中，由于倉儲(chǔ)的操作會(huì)直接被DataServiceController調(diào)用，而相關(guān)的查詢條件都是來自于RESTful API的，因此，很難在API的層面來確定某些聚合的對(duì)象屬性是否需要饑餓加載（Eager Loading）。另一方面，禁用延遲加載又會(huì)產(chǎn)生性能問題，因此，在當(dāng)前版本的實(shí)現(xiàn)中，我還沒有考慮好用何種方式來解決這個(gè)問題?；蛟S可以通過HTTP Header來指定需要饑餓加載的屬性路徑，但這是另一個(gè)問題?？傊诮酉聛淼陌咐?，你將看到，雖然數(shù)據(jù)已經(jīng)添加成功，但在返回的結(jié)果里，被聚合的子對(duì)象將無法返回。我會(huì)設(shè)法解決這個(gè)問題。
