如何将 .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.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 里,但是依然可以成功的访问。 

 

 

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

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

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

 

posted on 2020-04-11 15:16  清水栞  阅读(677)  评论(0编辑  收藏

导航