基於SqlSugar的開發框架循序漸進介紹（23）-- Winform端管理系統中平滑增加對Web API對接的需求

在前面隨筆介紹的基於SqlSugar的WInform端管理系統中，資料提供者是直接存取資料庫的方式，不過表單介面呼叫資料介面獲取資料的時候，我們傳遞的是標準的介面，因此可延伸性比較好。我曾經在隨筆《基於SqlSugar的開發框架循序漸進介紹（5）-- 在服務層使用介面注入方式實現IOC控制反轉》中介紹過，該SqlSugar開發框架本身是基於IOC控制反轉的，因此對於接入不同的資料提供者，只需要切換到對應的實現層上即可。本篇隨筆介紹基於SqlSugar開發框架的Winform端，實現包括對直接存取資料庫，遠端呼叫Web API介面的兩種不同的處理方式的整合。

1、Winform模組中對具體介面的呼叫及介面註冊

Winform中的介面展示，以及資料處理，都需要具體實現的支撐，由於本身IOC控制反轉的介面設計，我們對具體資料的存取，也是基於特定的介面層進行呼叫的，具體的實現，則是在程式啟動的時候，注入對應的介面實現即可。

例如對於客戶資訊的展示業務操作，程式碼如下所示

/// <summary>
/// 資料顯示的函數
/// </summary>
public async override void DisplayData()
{
    if (!string.IsNullOrEmpty(ID))
    {
        #region 顯示資訊
        var info = await BLLFactory<ICustomerService>.Instance.GetAsync(ID);
        if (info != null)
        {
            tempInfo = info;//重新給臨時物件賦值，使之指向存在的記錄物件        
            txtName.Text = info.Name;
            txtAge.Value = info.Age;
        } 
        #endregion
        //this.btnOK.Enabled = HasFunction("Customer/Edit");      
    }
    else
    {
        //this.btnOK.Enabled = HasFunction("Customer/Add");  
    }              
}

上面程式碼可以看到，我們是呼叫介面進行資料的處理的，而這個介面就是在程式啟動之處，通過自動的方式獲得對應的介面和實現類，然後進行注入的。

.net 中負責依賴注入和控制反轉的核心元件有兩個：IServiceCollection和IServiceProvider。其中，IServiceCollection負責註冊，IServiceProvider負責提供範例。

在註冊介面和類時，IServiceCollection提供了三種註冊方法，如下所示：

1、services.AddTransient<IDictDataService, DictDataService>();  // 瞬時生命週期
2、services.AddScoped<IDictDataService, DictDataService>();     // 域生命週期
3、services.AddSingleton<IDictDataService, DictDataService>();  // 全域性單例生命週期

如果使用AddTransient方法註冊，IServiceProvider每次都會通過GetService方法建立一個新的範例；

如果使用AddScoped方法註冊，在同一個域（Scope）內，IServiceProvider每次都會通過GetService方法呼叫同一個範例，可以理解為在區域性實現了單例模式；

如果使用AddSingleton方法註冊，在整個應用程式生命週期內，IServiceProvider只會建立一個範例。

前面說到，介面我們是自動遍歷響應的程式集進行註冊的，註冊介面的邏輯，我們可以統一抽取唯一個公用的函數處理，如下程式碼所示。

        /// <summary>
        /// 設定依賴注入物件
        /// </summary>
        /// <param name="services"></param>
        public static void ConfigureRepository(IServiceCollection services)
        {
            #region 自動注入對應的服務介面
            var path = AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory;
            var getFiles = Directory.GetFiles(path, "*.dll").Where(Match);  //.Where(o=>o.Match())
            var referencedAssemblies = getFiles.Select(Assembly.LoadFrom).ToList();  //.Select(o=> Assembly.LoadFrom(o))       
            
            var baseType = typeof(IDependency);  
            var types = referencedAssemblies
                .SelectMany(a => a.DefinedTypes)
                .Select(type => type.AsType())
                .Where(x => x != baseType && baseType.IsAssignableFrom(x)).ToList();
            var implementTypes = types.Where(x => x.IsClass).ToList();
            var interfaceTypes = types.Where(x => x.IsInterface).ToList();

            RegisterService(services, implementTypes, interfaceTypes);

            #endregion
        }

如果我們這裡增加一個對Web API的呼叫，那麼在這裡註冊的時候，切換向Web API代理的註冊介面就可以，如下圖所示。

因此原來的Winform介面上的呼叫程式碼，不需要任何變化，只需要注入不同的介面實現，就能獲得不同的方式：普通存取資料庫方式，還是分散式獲取服務WebAPI的處理方式。

通過切換開關變數的方式，客戶可以非常方便的自由切換不同的資料存取方式。資料提供服務，可以是直接存取資料庫的方式，也可以是遠端的Web API服務方式，從而實現更加廣泛的業務需求。

根據不同開關變數，處理不同的介面註冊的程式碼如下所示。

/// <summary>
/// 根據組態檔，決定採用直連的DLL，還是代理API的DLL，構建介面進行注入
/// </summary>
/// <param name="services"></param>
public static void ConfigureRepositoryAuto(IServiceCollection services)
{
    var config = new AppConfig();
    string callerType = config.AppConfigGet("CallerType");
    if (!string.IsNullOrWhiteSpace(callerType) && callerType.Equals("api", StringComparison.OrdinalIgnoreCase))
    {
        //如果設定為API模式
        ConfigureRepositoryApi(services);
    }
    else
    {
        //如果設定為普通模式
        ConfigureRepository(services);
    }
}

API方式的註冊，和普通的註冊方式類似，就是定位具體的實現，獲得介面和具體的實現物件，進行服務註冊即可，在此不再贅述。

2、具體的Web API代理實現

在隨筆《基於SqlSugar的開發框架循序漸進介紹（5）-- 在服務層使用介面注入方式實現IOC控制反轉》我們介紹過具體實現類的繼承關係，一般都是構建相應的基礎類別和介面，然後才是具體的業務實現和介面，這樣處理可以重用基礎類別的很多介面，提高程式碼的重用效率。

我們以其中簡單的Customer業務表為例，它的服務類程式碼如下所示（主要關注服務類的定義即可）。

    /// <summary>
    /// 客戶資訊應用層服務介面實現
    /// </summary>
    public class CustomerService : MyCrudService<CustomerInfo, string, CustomerPagedDto>, ICustomerService
    {
       ...............
    }

而對應Web API的代理呼叫類，那麼為了極大的重用常規的介面處理，我們需要類似的繼承關係。

具體的程式碼實現關係如下所示。

/// <summary>
/// 客戶資訊的Web API呼叫處理
/// </summary>
public class CustomerApiCaller : AsyncCrudApiCaller<CustomerInfo, string, CustomerPagedDto>, ICustomerService
{
}

我們可以利用程式碼生成工具生成主要的繼承關係，然後實現具體的函數封裝即可。我們獨立一個專案用來承載API的代理類處理。

在AsyncCrudApiCaller 類中做了很多Web API的呼叫封裝，對於介面的存取，是需要令牌的，因此在使用者存取其他介面前，需要獲取使用者身份令牌資訊，並快取起來供後續使用。

/// <summary>
/// 對使用者身份進行認證
/// </summary>
/// <param name="username">使用者名稱</param>
/// <param name="password">使用者密碼</param>
/// <returns></returns>
public async virtual Task<AuthenticateResultDto> Authenticate(string username, string password)
{
    var url = string.Format("{0}/api/Login/Authenticate", ServerRootAddress);
    var input = new
    {
        UsernameOrEmailAddress = username,
        Password = password
    };
    var result = await apiClient.PostAsync<AuthenticateResultDto>(url, input);
    return result;
}

後續每次介面存取的時候，填入相應的令牌資訊。

/// <summary>
/// 重新增加相應的請求頭，如認證的資訊
/// </summary>
protected virtual void AddRequestHeaders()
{
    //讀取需要設定的請求頭
    apiClient.RequestHeaders.Clear();
    foreach (var item in RequestHeaders)
    {
        apiClient.RequestHeaders.Add(item);
    }

    //從快取裡面讀取令牌資訊，並在請求的時候自動加入（如果沒有加的話）
    var accessToken = Cache.Instance["AccessToken"] as string;
    if (!string.IsNullOrWhiteSpace(accessToken))
    {
        var bearer = new NameValue("Authorization", "Bearer " + accessToken);
        if (apiClient.RequestHeaders != null && !apiClient.RequestHeaders.Contains(bearer))
        {
            apiClient.RequestHeaders.Add(bearer);
        }
    }
}

而ApiCaller的實現類此對於具體的呼叫，由於封裝了相應的處理類，因此操作程式碼是比較簡單的。

/// <summary>
/// 獲取所有物件列表
/// </summary>
/// <returns></returns>
public async virtual Task<ListResultDto<TEntity>> GetAllAsync()
{
    return await DoActionAsync<PagedResultDto<TEntity>>("all");
}

/// <summary>
/// 獲取所有物件列表
/// </summary>
/// <param name="input">獲取所有條件</param>
/// <returns></returns>
public async virtual Task<ListResultDto<TEntity>> GetAllByIdsAsync(IEnumerable<TPrimaryKey> input)
{
    return await DoActionAsync<PagedResultDto<TEntity>>("all-byids", input);
}

GET引數可以選用Dict方式傳遞，或者直接傳入匿名類也可以，後臺程式碼自動生成相關的URL引數傳遞的。

public async Task<bool> SetDeletedFlag(int id, bool deleted = true)
{
    var action = $"set-deleted";
    var input = new
    {
        id,
        deleted
    };
    return await DoActionAsync<bool>(action, input, HttpVerb.Post);
}
public async Task<OuInfo> FindByName(string name)
{
    var action = $"byname/{name}";
    var dict = new Dictionary<string, string> { { "name", name } };
    return await DoActionAsync<OuInfo>(action, dict, HttpVerb.Get);
}

剩下的任務就是完善ApiCaller專案的類，與Web API控制器提供的介面的對應關係了，處理完成後，就可以進行測試了。

只要做好模組介面的對接關係，介面的處理程式碼不用變化就可以切換到其他方式上去了（如Web API的資料提供方式）。