程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> C#入門知識 >> Web API項目中使用Area對業務進行分類管理，apiarea

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

編輯：C#入門知識

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

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