基於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的數據提供方式）。