在之前開發的很多Web API項目中，為了方便以及快速開發，往往把整個Web API的控制器放在基目錄的Controllers目錄中，但隨著業務越來越復雜，這樣Controllers目錄中的文件就增加很快，難以管理，而且如果有不同業務模塊有重復的控制器名的話，還需要盡量避免。引入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
上面小節介紹了使用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，然後構建具體業務范疇下的控制器接口即可。
所有的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接口調用，具體使用客戶端的代碼如下所示。
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，這樣我們所有的數據入口在一個地方，可以集中業務接口的統一開發，並且可以有效管理我們的數據提供的性能問題，如統一緩存處理，統一權限處理...
感謝大家對本文章的細心閱讀，希望對您的開發有所啟發或幫助。
