单层应用升级到多层应用3

接上文，我们已经初步完成了单层到多层的拆分，接下来就是再优化我们的结构了。

升级思路

在前文的Core项目中，包含了我们所有的基础功能，但是有些项目可能只需要部分功能却引用整一块Core的话，会显得有些多余，需要将这部分基础设施再做一下细致化的拆分。 在Host项目中，仍旧还有许多功能代码没有拆分，如EventBus，FileStoreages， Authorization，Localization等，这部分又算基础设施功能，一部分又有一定的业务属性。需要将这些功能抽象拆分出来。

开始迁移

再来回顾我们单层的目录结构，如图：

image.png

抽离DependencyInjection

首先考虑依赖注入的基础功能，这一部分是最通用的，完全可以单独放在一块。 新建类库Wheel.DependencyInjection，将三个依赖注入的接口迁移过去。很简单。

image.png

抽离Authorization

在上一篇文章中，我们的Authorization相关的代码还是放在Host中，但是这一块可以完全剥离处理，里面只包含：IPermissionChecker，PermissionAuthorizationHandler，PermissionAuthorizationPolicyProvider和PermissionAuthorizationRequirement四个代码文件。 新建类库Wheel.Authorization，把4个代码文件迁移过去，这里不包含IPermissionChecker的实现。需要依赖Wheel.DependencyInjection类库完成来做依赖注入。

image.png

抽离Cache

缓存也是属于非常基础的功能，按需引用来使用。 新建类库Wheel.Cache，将Cache中的文件迁移过去。无需依赖其他项目引用。

抽离User

ICurrentUser是根据请求获取当前用户数据的接口，也是根据业务场景使用的玩意。这里也抽出来。 新建一个类库Wheel.Users，将CurrentUser和ICurrentUser文件迁移过去。这里由于CurrentUser用到了IHttpContextAccessor来获取Http请求上下文，是Asp.Net Cored的API，需要在项目文件中添加Asp.Net Core的框架依赖:

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App"></FrameworkReference>
</ItemGroup>

抽离Permissions

前面我们抽离Authorization的时候没有把IPermissionChecker的实现迁移过去，这里是把实现放在Permissions中。 新建类库Wheel.Permissions，依赖引用Authorization，Cache和Users。把PermissionChecker迁移到类库。

抽离Utilities

Utilities是我们的一些工具类。非常适合抽离出来单独引用。 新建类库Wheel.Utilities，依赖DependencyInjection，然后将Utilities目录中的文件迁移过来。

image.png

抽离EventBus

我们的EventBus分成了LocalEventBus和DistributedEventBus，同时又有不同的实现。所以这里EventBus则是按照实现来拆分成多个类库。 首先把基础接口抽离单独一个类库Wheel.EventBus：

image.png

这里包括了EventBus和Handler的相关接口。 然后我们按照实现分别再新建类库。

Wheel.EventBus.Cap

新建类库Wheel.EventBus.Cap，依赖引用Wheel.EventBus项目，然后把CAP实现代码迁移到这个项目中。

image.png

Wheel.EventBus.MediatR

新建类库Wheel.EventBus.MediatR，依赖引用Wheel.EventBus项目，然后把MediatR实现代码迁移到这个项目中。

image.png

Wheel.EventBus.Channels

新建类库Wheel.EventBus.Channels，依赖引用Wheel.EventBus项目，然后把Channels实现代码迁移到这个项目中。

image.png

拆分完后，我们后续使用EventBus只需要按照需要引用相关的实现即可。

抽离FileStorages

FileStorages跟EventBus一样，可能会有多个实现的类型，所以我们也按照EventBus的方式来拆分。 首先是新建一个类库Wheel.FileStorages，把FileStorages的基础接口和类迁移进来。

image.png

Wheel.FileStorages.Minio

我们暂时只对接了Minio，所以只新建一个Wheel.FileStorages.Minio类库，把Minio的实现部分迁移到这里。

image.png

拆分完后，我们后续使用FileStorages只需要按照需要引用相关的实现即可。

抽离Json

新建一个类库Wheel.Json，里面放的是一些JsonConverter，按照需要引用使用即可。

image.png

抽离Localization

新建一个类库Wheel.Localization，将Localization相关的代码迁移进来，这里我们没有把EFStringLocalizerStore加进来，因为这部分跟数据库有关，所以我们把实现还是放在了Host中，相对的添加一个NullStringLocalizerStore作为默认实现。

image.png

抽离Settings

新建一个类库Wheel.Settings，这部分跟Localiztion差不多，都需要一个ISettingStore的默认实现。

image.png

最终结构

最终整个解决方案的结构如下图所示：

image.png

对比最初的单层应用，是否瞬间感觉完全不一样了。项目结构变得更加清晰，层次更加分明。 同时我们也逐渐形成了我们框架基础设施的部分。这部分和业务无关，在开发新的业务项目时，这部分基础设施可以快速的应用到我们的新项目上，大大减少了重复开发基础设施的工作量。

多层拆分后的代码地址：https://github.com/Wheel-Framework/Wheel/tree/multi-layer