如何将 .NetFramework WebApi 按业务拆分成多个模块
如何将 .NetFramework WebApi 按业务拆分成多个模块
在 .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 ，就是你的 WebAppModule。
public class MyWebApiApplication : RefaceHttpApplication
{
}
这样，就会在 Web 应用程序启动的时候，完成 Reface.AppStarter 中的所有过程。
提示 :
这个 RefaceHttpApplication 只是封装了 AppSetup.Start 的过程，你也可以不继承此类，并手动完成对 AppSetup 的启动。
Step 6 - 配置文件
通过 RefaceHttpApplication 启动，会以站点根目录的 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》
有关 事件总线，会在后面的文章中向大家介绍。
