ABP開發框架先後端開發系列---（16）ABP框架升級最新版本的經驗總結

有一小段時間沒有持續升級ABP框架了，最近就因應客戶的須要，把ABP框架進行全面的更新，因爲咱們應用的ABP框架，基礎部分仍是會使用官方的內容，所以升級的時候須要把官方基礎ABP的DLL進行全面的更新，以及對應的引用DLL也同步更新才行。不過在升級過程當中仍是不少奇奇怪怪的問題，本篇隨筆針對出現的狀況進行一系列的總結，以便後面有一個對照參考吧。

一、最新案例源碼和NugGet程序包更新

ABP官方的基礎模塊更新速度仍是很快的，一段時間過去，就跳過了幾個版本號，我是在舊版本的基礎上進行手動的NugGet更新，可是基於VS的Nugget老是更新卡頓，不知不覺就沒有反應了，嚴重影響開發的效率。所以先從官方下載的Demo案例中把相關部分源碼進行更新。

官方的案例源碼下載地址是：https://aspnetboilerplate.com/Templates 

1）最新案例源碼結構和部份內容調整

咱們從其中下載對應的源碼，而後根據項目結構中的對應源碼文件，使用Beyond Compare對比文件進行文件逐一對比，原則上除了我的擴展的部分，都以官方的源碼作法爲準便可。

目前ABP官方最新的DLL版本是5.3.0，能夠下載的Demo版本是5.2.0，它們應該差異不大。下載下來的Aspnet-core部分的源碼結構以下所示。

而咱們的ABP框架是在這個基礎上進行必定的結構優化，以更加方便快速的開發，以及結合代碼生成工具進行快速的使用。

咱們的VS項目結構 以下所示。

以上是VS裏面解決方案的項目結構，我根據項目之間的關係，整理了一個架構的圖形，以下所示。

 上圖中，其中橘紅色部分就是咱們爲各個層添加的類或者接口，分層上的序號是咱們須要逐步處理的內容。

應用服務層是整個ABP框架的靈魂所在，對內協同倉儲對象實現數據的處理，對外配合Web.Core、Web.Host項目提供Web API的服務，而Web.Core、Web.Host項目幾乎不須要進行修改，所以應用服務層就是一個很是關鍵的部分，須要考慮對用戶登陸的驗證、接口權限的認證、以及對審計日誌的記錄處理，以及異常的跟蹤和傳遞，基本上應用服務層就是一個大內總管的角色，重要性不言而喻。

回顧瞭解一下咱們改造過的ABP開發框架的結構後，咱們返回到版本升級的主體上來介紹。

目前我把VS的版本升級到最新，其.net framework支持4.8, 並單獨安裝了dotnetcore最新版本3.1，所以環境是最新的，而基礎的ABP 5.3.0也是採用了.net core3.1。

對比源碼，咱們能夠發現，Web.Host和Web.Core項目裏面已經有所差別，IHostingEnvironment已經被拋棄使用，而採用dotnetcore最新對象IWebHostEnvironment來替代了。

 替換最新源碼爲

所以Web.Host項目中的Module類也進行了調整。

相對應的Web.Core項目裏面的Module也同時進行調整了。

 

2）NugGet程序包更新

Nugget程序包的更新，原則上能夠選擇單個項目進行更新，或者選擇整個解決方案進行程序包的更新，前者可能相應速度快一些，後者因爲解決方案項目數量問題，可能會較慢。

我早期的基礎ABP版本是4.9，所以想一次性整個的解決方案的程序包進行更新，不過嘗試屢次，花了幾個小時，都沒法順利進行項目的所有更新，因而單個項目進行更新，也很是慢。

因而也經過推薦採用Nugget最新地址進行更新，以下設置更新源。

在程序包源中添加：https://api.nuget.org/v3/index.json 

 

 響應速度相對快了一些，沒有不常常的出問題了。

咱們若是須要單獨更新某個項目的程序包，那麼須要選擇項目，選擇【管理Nugget程序包】進入界面更新便可。以下界面所示。

通常狀況下，咱們推薦對整個解決方案進行全面的程序包更新，以下選擇解決方案，而後進入對應Nugget程序包管理界面更新便可。

這樣的所有更新解決方案的程序包，若是可以順利完成，那是皆大歡喜，不過可能會稍微慢一些。若是不行，只有逐個更新程序包了。

我以前選擇這樣的方式更新的時候，老是有一兩個程序包更新出錯，所以只有使用npm 控制檯進行單獨的升級了。

 

二、ABP框架基類封裝接口命名調整

在更新ABP基礎模塊的時候，發現ABP的基礎接口所有調整了命名，如原來的Get變爲GetAsync，GetAll變爲 GetAllAsync，Delete變爲了DeleteAsync，Update變爲了UpdateAsync，Create變爲了CreateAsync。

也就是說，他們所有采用了異步名稱的命名規則，在異步方法後面所有加上了Async做爲標識。

我在以前模塊介紹過ABP框架的基礎接口。IAsyncCrudAppService定義了幾個通用的建立、更新、刪除、獲取單個對象和獲取全部對象列表的接口，接口定義以下所示。

namespace Abp.Application.Services
{
    public interface IAsyncCrudAppService<TEntityDto, TPrimaryKey, in TGetAllInput, in TCreateInput, in TUpdateInput, in TGetInput, in TDeleteInput> : IApplicationService, ITransientDependency
        where TEntityDto : IEntityDto<TPrimaryKey>
        where TUpdateInput : IEntityDto<TPrimaryKey>
        where TGetInput : IEntityDto<TPrimaryKey>
        where TDeleteInput : IEntityDto<TPrimaryKey>
    {
        Task<TEntityDto> Create(TCreateInput input);
        Task Delete(TDeleteInput input);
        Task<TEntityDto> Get(TGetInput input);
        Task<PagedResultDto<TEntityDto>> GetAll(TGetAllInput input);
        Task<TEntityDto> Update(TUpdateInput input);
    }
}

如今這些接口所有調整以下所示了。

namespace Abp.Application.Services
{
    public interface IAsyncCrudAppService<TEntityDto, TPrimaryKey, in TGetAllInput, in TCreateInput, in TUpdateInput, in TGetInput, in TDeleteInput> : IApplicationService, ITransientDependency
        where TEntityDto : IEntityDto<TPrimaryKey>
        where TUpdateInput : IEntityDto<TPrimaryKey>
        where TGetInput : IEntityDto<TPrimaryKey>
        where TDeleteInput : IEntityDto<TPrimaryKey>
    {
        Task<TEntityDto> CreateAsync(TCreateInput input);
        Task DeleteAsync(TDeleteInput input);
        Task<PagedResultDto<TEntityDto>> GetAllAsync(TGetAllInput input);
        Task<TEntityDto> GetAsync(TGetInput input);
        Task<TEntityDto> UpdateAsync(TUpdateInput input);
    }
}

那麼這些咱們都必須隨着ABP框架的調整也同時進行接口和對應類實現的調整了。

例如對應的異步ApplicationService服務的基類封裝，咱們也須要調整對應的異步接口實現。

針對遠程調用的ApiCaller接口和實現，咱們也須要進行命名方面的統一調整，這樣才能順利進行異步接口的調用 

 我在以前隨筆《ABP開發框架先後端開發系列---（10）Web API調用類的簡化處理》有針對API調用層的簡化處理作了說明，咱們全部的API調用，基本都是經過統一的一個函數進行調用的。

統一調用處理的方法名稱是DoActionAsync。

雖然因爲前面介紹了應用服務層的接口不少接口增長了Async的後綴字符，可是客戶端經過URL調用，這個Async是不須要的，也就是須要移除，咱們以前組裝的URL地址是根據函數名稱，那麼函數名稱須要移除這個後綴的Async字樣了。

這樣系統就順利跑起來了。服務端界面以下所示。

 

 

 咱們啓動Winform客戶端，界面以下所示。

 

登錄啓動後主體界面以下所示