Web API項目中使用Area對業務進行分類管理

標籤：

在之前開發的很多Web API項目中，為了方便以及快速開發，往往把整個Web API的控制器放在基目錄的Controllers目錄中，但隨著業務越來越複雜，這樣Controllers目錄中的檔案就增加很快，難以管理，而且如果有不同業務模組有重複的控制器名的話，還需要盡量避免。引入Area的作用就是把控制器按照不同的業務模組進行區分，方便管理，而且控制器名稱可以重名。

1、Web API項目引入Area進行分類

Area在項目中可以稱之為地區，每個Area代表應用程式的不同功能模組，Area 使每個功能模組都有各自的檔案夾，檔案夾中有自己的Controller、View和Model，但對於管理也增加了一定的難度。如果是Web API項目，我們可以把不必要的目錄移除即可，簡化對目錄的管理。
引入Area可以是我們不同的業務模組可以重名，而且各個業務模組管理起來也更加方便，在原先的Web API項目裡面，它們的目錄是這樣的。

雖然我們把它們的目錄歸類，但是它們還是存放在一個命名空間下的。

namespace MyWebApi.Controllers

 

這樣使用雖然也沒有什麼問題，但是還是存在一些弊端，因此引入Area的方式對不同業務模組的控制器進行管理，以達到我們分類管理的目的。
引入Area前，我們的API路徑如下所示

http://localhost:9001/api/User

引入Area後，我們把常規的許可權管理、字典管理等基礎模組放到Framework的Area裡面，那麼這個時候API路徑和具體的Area相關，地址則變成了如下：

http://localhost:9001/api/Framework/User

我們再來看看具體的項目目錄，Web API項目中使用Area後，Controller的目錄如下所示。

除了在各個不同Area下有不同的控制器，而且也增加了一個**AreaRegistration.cs的檔案，如對應Framework的Area，有一個FrameworkAreaRegistration.cs檔案
這樣對應下面的控制器，它的命名空間如下所示。

namespace WebAPI.Areas.Framework.Controllers

 

2、Web API項目對Area控制器的路徑映射

上面小節介紹了使用Area來對Web API控制器的分類管理，並介紹了引入Area後對控制器位置、命名空間、Web API的URL等方面的不同。這樣如果我們要解析對應地址的Web API，那麼也需要做一定的處理，否則是無法找到對應的控制器，從而出現錯誤資訊。
首先我們需要修改Web API裡面WebApiConfig的配置資訊，如下所示。

上面指定了預設的Web API映射，並指定結果只做JSON格式的輸出（移除XML輸出）。
為了對不同的Area實現API的地址處理，我們先設計一個基類，然後讓不同的Area註冊類繼承它，方便統一處理。

其中基類Area註冊類的CustomAreaRegistration類代碼如下所示。

有了上面的基類映射 RegisterArea函數，我們只需要在子類設定對應的AreaName基類實現不同Area子類的正確映射API路徑處理了。

/// <summary>/// 架構基礎Area的註冊類/// </summary>public class FrameworkAreaRegistration : CustomAreaRegistration {    public override string AreaName     {        get         {            return "Framework";        }    }}

 

當然為了實現對Area的Web API控制器的URL正確解析，擷取屬於Action、Controller、以及對應命名空間的對象，那麼還需要在global.asa.cs裡面添加一行代碼，如下所示。

 //對Web API的Area進行支援GlobalConfiguration.Configuration.Services.Replace(typeof(IHttpControllerSelector),  new AreaHttpControllerSelector(GlobalConfiguration.Configuration));

 

其中AreaHttpControllerSelector是我們自訂的HTTP控制器位址解析器，需要根據我們的地址提取出具體的控制器、Area名稱、程式集類型等，方便構建對應的解析器。

private HttpControllerDescriptor GetApiController(HttpRequestMessage request){    var controllerName = base.GetControllerName(request);    var areaName = GetAreaName(request);    if (string.IsNullOrEmpty(areaName))    {        return null;    }    var type = GetControllerTypeByArea(areaName, controllerName);    if (type == null)    {        return null;    }    return new HttpControllerDescriptor(_configuration, controllerName, type);}

 

有了這些基礎的管理，我們就可以定義好我們所需要Area，然後構建具體業務範疇下的控制器介面即可。

3、Web API在用戶端的介面調用

所有的Web API地址，都是與具體的Area有關係，例如在Framework業務下的字典模組，它們Web API配置的地址如下所示。

<!--字典Web API模組配置-->

<add key="DictType" value="http://localhost:27206/api/Framework/DictType"/>

<add key="DictData" value="http://localhost:27206/api/Framework/DictData"/>

<add key="CorpDictData" value="http://localhost:27206/api/Framework/CorpDictData"/>

<add key="City" value="http://localhost:27206/api/Framework/City"/>

<add key="District" value="http://localhost:27206/api/Framework/District"/>

<add key="Province" value="http://localhost:27206/api/Framework/Province"/>

<add key="UserParameter" value="http://localhost:27206/api/Framework/UserParameter"/>

我們在用戶端，只需要對Web API進行封裝即可，這個部分可以使用Database2Sharp代碼產生工具進行統一的產生，所有繼承關係統一處理好，我們所做的就是進行新增介面的處理即可。
例如對於字典模組DictData的處理，它對於Web API的封裝類如下所示。

/// <summary>/// DictData, 基於API服務的Facade介面實作類別/// </summary>public class DictDataCaller : BaseApiService<DictDataInfo>, IDictDataService

 

這個基類，預設封裝了對常規資料表業務Web API介面方式的增刪改查以及各種複雜的介面處理。
如果對於一般的Web API（非資料表業務），那麼只需要繼承的基類做調整即可。

/// <summary>/// 基於API服務的Facade介面實作類別/// </summary>public class TestCaller : NormalApiService, ITestService

 

這個NormalApiService基類，預設只是封裝了對token和簽名的讀取處理，沒有特殊的業務介面，具體特定的介面我們來實現處理。

對於WebAPI用戶端的調用，我們主要就是需要構建對應的URL，然後通過GET傳遞或者POST傳遞一些參數，並讀取HTML結果，把它解析為對應的類型資料即可，如下代碼所示。

/// <summary>/// 根據字典類型名稱擷取對應的字典記錄/// </summary>/// <param name="dictTypeName">字典類型名稱</param>/// <returns></returns>public List<DictDataInfo> FindByDictType(string dictTypeName){    var action = System.Reflection.MethodBase.GetCurrentMethod().Name;    string url = GetTokenUrl(action) + string.Format("&dictTypeName={0}", dictTypeName);    List<DictDataInfo> result = JsonHelper<List<DictDataInfo>>.ConvertJson(url);    return result;}

 

通過GetTokenUrl(action) 函數擷取對應的URL地址，由於傳入一個參數，介面這裡沒有發生資料修改，是GET方式提交參數資料，因此把參數附加在URL即可。
也就是下面代碼實現了完整Web API地址的構建。

string url = GetTokenUrl(action) + string.Format("&dictTypeName={0}", dictTypeName);

構建好這些URL地址後，我們通過擷取對應Web API的結果並進行序號到具體對象即可。如下代碼所示。

List<DictDataInfo> result = JsonHelper<List<DictDataInfo>>.ConvertJson(url);

關於Web API介面的設計文章，可以參考我的隨筆。

• Web API介面設計經驗總結
• Web API應用架構設計分析（1）
• Web API應用架構設計分析（2）
  具體的Web API介面的使用，可以參考隨筆：
• Web API應用架構在Winform混合架構中的應用（1）
• Web API應用架構在Winform混合架構中的應用（2）--自訂異常結果的處理
• Web API應用架構在Winform混合架構中的應用（3）--Winfrom介面調用WebAPI的過程分解
• Web API應用架構在Winform混合架構中的應用（4）--利用代碼產生工具快速開發整套應用
• Web API應用架構在Winform混合架構中的應用（5）--系統層級字典和公司層級字典並存的處理方式

通過以上的封裝處理，那麼對於業務表的Web API介面調用，具體使用用戶端的代碼如下所示。

var dictType = CallerFactory<IDictTypeService>.Instance.GetTree();Console.WriteLine(dictType.ToJson());var dictData = CallerFactory<IDictDataService>.Instance.GetAllDict();Console.WriteLine(dictData.ToJson());

 

如果對於非資料表業務的Web API介面調用，具體使用用戶端的代碼如下所示。

var testAction = CallerFactory<ITestService>.Instance.TestAction();Console.WriteLine(testAction.ToJson());var test = CallerFactory<ITestService>.Instance.Test("123");Console.WriteLine(test.ToJson());

 

這樣，不管是在Web項目裡面，還是在Winform項目裡面，或者在跨平台的IOS項目裡面（或者安卓項目），都可以以相同的方式消費Web API，這樣我們所有的資料入口在一個地方，可以集中業務介面的統一開發，並且可以有效管理我們的資料提供的效能問題，如統一緩衝處理，統一許可權處理...
感謝大家對本文章的細心閱讀，希望對您的開發有所啟發或協助。

Web API項目中使用Area對業務進行分類管理