在之前開發的很多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，這樣我們所有的數據入口在一個地方，可以集中業務接口的統一開發，并且可以有效管理我們的數據提供的性能問題，如統一緩存處理，統一權限處理...
感謝大家對本文章的細心閱讀，希望對您的開發有所啟發或幫助。

主要研究技術：代碼生成工具、會員管理系統、客戶關系管理軟件、病人資料管理軟件、Visio二次開發、酒店管理系統、倉庫管理系統等共享軟件開發
專注于Winform開發框架/混合式開發框架、Web開發框架、Bootstrap開發框架、微信門戶開發框架的研究及應用。
??轉載請注明出處：
撰寫人：伍華聰??http://www.iqidi.com?

總結

以上是生活随笔為你收集整理的【转】Web API项目中使用Area对业务进行分类管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。