在 .NetFramework中使用WebApi ，在不討論 微服務 的模式下，大部分都是以層來拆分庫的 :

• 基礎設施
• 資料儲存層
• 服務層
• WeApi層
• 一些其它的功能庫

專案結構可能會像下面這樣子

有些人可能會將其中的資料儲存層、服務層按業務功能進行垂直拆分，

但是到了 WebApi這層，就不得不把所向所有業務功能的 Controller都堆在這兒了。

隨著業務的堆積，WebApi這層的程式碼量越來越大，耦合性也越來越強，越來越難維護。

…

……

………

…………

這時候，微服務 就出現了。

可是，微服務給系統所帶來的複雜程度是極高的，

在某些場景下，轉微服務可以很好的解決這些問題，但是又會帶來更多的新問題，

所以我們希望有一種模式，即能像微服務那樣對程式碼進行垂直切分，又能保持簡單易維護的單體應用程式模式。

打算在單體應用程式中解決這種趨於臃腫問題，我們可以借鑑微服務那種 按業務垂直拆分的思想。

但是與微服務不同是，它依然是單啟動程式，這個啟動程式能夠組織出散落在各個模組中的所有WebApi並暴露給外部。

換個角度思考，其實就是將業務模組化 。

微軟維護的Ochard框架很好的實現了這些功能，但是使用 Orchard可能會給你帶來以下問題

• 這是一個非常重型的框架，程式碼量比較大，執行速度不佳
• 幾乎沒有什麼中文的文件（最多隻能找到 HelloWorld這樣的淺顯的教程 )
• 官網文件是英文的，對閱讀有較高的要求，而且速度很慢，需要使用正確的閱讀方式
• 系統中充斥著大量的隱匿約束（在型別名稱上的約束，前端更是使用了大量的 DynamicObject ，很難了解到到底包含了哪些可用成員 )

....

於是我基於 Reface.AppStarter開發了一套輕量級的模組化 WebApi框架 【 Reface.AppStarter.WebApi 】，它實現了以下功能

• 垂直拆分你的 WebApi Controller至不同的 Library
• 開箱即用的 Controller建構函式注入
• 具備 Reface.AppStarter中的 EventBus和 CommandBus 功能，可以很好的進行模組間的通訊
• 在啟動模組決定啟動哪些業務模組

使用 Reface.AppStarter.WebApi很簡單，它對原來的開發風格幾乎沒有什麼影響，

下面將演示如何使用 Reface.AppStarter.WebApi將 WebApi專案拆分至各種模組

Step 1 -建立空的 WebApi專案

建立一個 WebApi專案，但是你不需要在這裡寫任何的 Controller,它只是你的啟動程式，不需要為它編寫任何與啟動無關的程式碼。

為你的 WebApi新增 Nuget 引用 Reface.AppStarter。

Step 2 -建立業務庫

建立業務 Library ，比如 Users，你將在這個 Library中實現有關 Users的所有功能，包括 Controller。

通過 Nuget引用 Reface.AppStarter.NPI

Step 3 -在業務庫中編寫控制器

為 Users Library新增一個 Controllers的目錄，並編寫你的控制器

[ApiRoute("hello")]
public class HelloController : ApiController
{
    [Route]
    public string Get()
    {
        return "HelloWorld!";
    }
}

Reface.AppStarter.NPI包含了編寫一個 WebApi的所有依賴項。

因此你只要通過 Nuget添加了 Reface.AppStarter.NPI就可以編寫屬於你的 ApiController 。

如果你需要向控制器中注入一些其它的元件，你只要通過建構函式注入即可：

[ApiRoute("hello")]
public class HelloController : ApiController
{
    private readonly IHelloService helloService;

    public HelloController(IHelloService helloService)
    {
        this.helloService = helloService;
    }

    [Route]
    public string Get()
    {
        return "HelloWorld!";
    }
}

Step 4 -編寫業務庫的 AppModule

為你的 Users Library編寫一個 AppModule 。

在 Reface.AppStarter框架模式下，每一個 Library都至少要提供一個 AppModule ，以供給其它模組依賴。

你的 Users也不例外，

UsersAppModule 需要使用 WebApi功能，因此 UsersAppModule 要依賴 WebApiAppModule

[WebApiAppModule]
public class UsersAppModule : AppModule
{
}

如果你還需要自動配置、自動 IOC / DI註冊裝配，那你也可以根據你的需求新增其它的 AppModule。

Step 5 -讓你的啟動專案依賴 UsersAppModule

首先，你需要為你啟動專案建立一個 AppModule ，比如 WebAppModule

[UsersAppModule]
public class WebAppModule : AppModule
{
}

然後你需要建立一個Global.asax，相信大家應該都知道這是個什麼吧。

修改你的Global.asax檔案，使其繼承於RefaceHttpApplication<T> ，這裡的 T ，就是你的 WebAppModule。

public class MyWebApiApplication : RefaceHttpApplication<WebAppModule>
{
}

這樣，就會在 Web應用程式啟動的時候，完成 Reface.AppStarter中的所有過程。

提示 :

• 這個 RefaceHttpApplication<T>只是封裝了 AppSetup.Start的過程，你也可以不繼承此類，並手動完成對 AppSetup的啟動。

Step 6 -配置檔案

通過 RefaceHttpApplication<T>啟動，會以站點根目錄的 app.json檔案作為 Reface.AppStarter框架內的配置檔案。

Reface.AppStarter.WebApi 內只有一個Config型別，它允許重新定義所有WebApi的路由字首

{
  "WebApi": {
    "Prefix": "myapi"
  }
}

你可以通過修改這個 Prefix來修改所有控制器的字首名稱，（ 預設值是 api ）。

Step 7 -執行

執行你的啟動程式吧，並鍵入 /myapi/hello你就會看到 HelloController雖然寫在了別的 Library裡，但是依然可以成功的訪問。

至此就介紹了 Reface.AppStarter.WebApi中的主要功能。

有關 Reface.AppStarter相關功能，可以閱讀 《https://www.cnblogs.com/ShimizuShiori/p/12610668.html》

有關事件匯流排，會在後面的文章中向大家介紹。

關注公眾平臺【清水潭】，可以查閱更多資料