自定义现有模块

ABP框架提供的设计旨在支持构建完全模块化的应用程序和系统. 它还提供了一些可以在任何类型的应用程序中使用的预构建应用模块

例如,你可以在你的应用程序中重用身份管理模块去添加用户,角色和权限管理. 应用程序启动模板已经预装了Identity和其他模块.

复用应用模块

你有两个选项去复用应用模块:

你可以添加相关模块的 NuGet 和 NPM 包引用到你的应用程序,并配置模块(根据它的文档)集成到你的应用程序中.

正如前面提到,应用程序启动模板已经预装了一些基本模块,它引用模块的NuGet和NPM包.

这种方法具有以下优点:

你的解决方案会非常干净,只包含你自己的应用程序代码.
你可以很简单的升级模块到最新的可用模板. abp update CLI 命令会使更新变的更加简单. 通过这种方式, 你可以获得最新功能和Bug修复.

然而有一个缺点:

本文档介绍了 或者自定义或扩展 依赖模块并且无需更改其源码,尽快与更改完整的源码比起是有限的,但仍有一些好的方法可以自定义.

如果你不认为自己会对预构建的模块进行重大更改,那么使用包引用的方法复用模块是推荐的方法.

如果你想要在预构建的模块上进行重大更改或添加主要功能,但是可用的扩展点不够使用,那么可以考虑直接使用依赖模块的源码.

这种情况下,你通常添加模块源码到你的解决方案中,并将包引用替换为本地项目引用. ABP CLI 可以为你自动化这一过程.

你可能不希望将模块源代码直接包含在解决方案中. 每个模块都包含十多个项目文件,添加多个模块会使解决方案变的臃肿可能还会影响开发时的加载速度,另外你可能有不同的开发团队维护不同模块.

无论如何,你都可以为需要的模块创建单独的解决方案,将依赖模块做为解决方案中的项目引用. 比如在abp仓库,我们就是这样做的.

我们看到的一个问题是Visual Studio在这种方式下不能很好的工作(解决方案目录之外对本地项目的引用不能很好地支持). 如果在开发过程中出错(对于外部模块),请在Visual Studio打开应用程序的解决方案后,在命令行运行 dotnet restore命令.

一个备选方案是将重新打包模块的源代码(NuGet/NPM包),使用包引用. 你可以为公司使用本地私人的Nuget/NPM服务器.

如果你决定使用预构建模块的NuGet/NPM包引用方式. 下面的文档详细解释了如何自定义/扩展现有模块的方法:

另外,请参阅以下文档: