如何将 .NetFramework WebApi 按业务拆分成多个模块

在 .NetFramework 中使用 WebApi ，在不讨论 微服务 的模式下，大部分都是以层来拆分库的 :

基础设施
数据存储层
服务层
WeApi 层
一些其它的功能库

项目结构可能会像下面这样子

如何将 .NetFramework WebApi 按业务拆分成多个模块-LMLPHP

有些人可能会将其中的 数据存储层、服务层 按业务功能进行垂直拆分，

但是到了 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.WebApi

Step 3 - 在业务库中编写控制器

为 Users Library 添加一个 Controllers 的目录，并编写你的控制器

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

Reface.AppStarter.WebApi 包含了编写一个 WebApi 的所有依赖项。

因此你只要通过 Nuget 添加了 Reface.AppStarter.WebApi 就可以编写属于你的 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 里，但是依然可以成功的访问。

如何将 .NetFramework WebApi 按业务拆分成多个模块-LMLPHP

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

有关 Reface.AppStarter 相关功能，可以阅读《https://www.cnblogs.com/ShimizuShiori/p/12610668.html》

有关 事件总线，会在后面的文章中向大家介绍。

如何将 .NetFramework WebApi 按业务拆分成多个模块-LMLPHP

关注公众平台【清水潭】，可以查阅更多资料

清水栞