基于ABP框架的业务与主服务分离的总结与讨论

这篇文章是对基于ABP框架的业务与主服务分离的总结与讨论。

投简历的时候是不是有人问我有没有abp的开发经历，汗颜！

在各位大神的尝试及自己的总结下，还是实现了业务和主机服务分离，通过dll动态的加载卸载，控制器动态的删除添加。

项目如下：

演示效果：

下面就是代码部分：

重点

1.IActionDescriptorChangeProvider接口，(关于添加删除可以通过后台任务检测刷新，移除控制器操作)

2.builder.Services.AddControllers().ConfigureApplicationPartManager和AssemblyLoadContext搭配加载业务的dll（动态链接库）。

我的业务代码很简单，可能有人要说了，那复杂的业务，有很多业务类，注入这块怎么办，怎么实现整个的调用链。

关于业务和主服务之间的关联代码就在这了

看下面的项目，有没有一点模块化开发的感觉，但是这次分离的很彻底，只需要dll就行，不需要程序集引用。

以Assembly为单位做存储

在初次加载的时候注入Imodule，并且缓存起来，这样避免了反射的操作，之前的做法是通过反射来拿IModule

再看看Program是怎么写的，等等，为什么注释掉了重要的代码呢

这里先对上面的尝试做个总结:

模块化开发通过IModule分离各个模块解耦，通过dll把接口加入到主程序，很nice,但是，我还想更深入一层，把这个接口也一并做成可拔可插，这样就不得不考虑如何动态的重载controller，这也没问题。重中之重来了，上面的都做到了，但是我要的不仅仅是增加删除一个controller，关联的业务代码发生了改变如何重载刷新，依赖注入这一块绕不过去。并没有好的解决办法，就这样项目戛然而止。

目前有两种解决办法：

1.加个中间层，通过反射去动态获取业务实现

2.业务实现通过new对象来拿。

下面是代码：

所有的注入业务放到单独的注入文件中，

上面的代码可以再加一层代理，类似这样

由于这层代码没有走依赖注入，想用各种aop组件，灵活性稍微低了一点点。

下面第二种直接在业务代码中new对象也不是不可，这一层的前后需要的都可以注入到容器里面去。只不过这一层就想到包装类一层不要在使用这个类的时候做过多的职责承担

使用的时候就直接拿实例：

demo源代码：

liuzhixin405/AspNetCoreSimpleAop (github.com)

未经允许不得转载：大白鲨游戏网 » 基于ABP框架的业务与主服务分离的总结与讨论