开发人员使用哪种设计模式 Abp 框架 (abp.io)？

Posted 2023-02-15

【中文标题】开发人员使用哪种设计模式 Abp 框架 (abp.io)？

【英文标题】：Which design pattern Abp Framework (abp.io) are developers using?

【发布时间】：2020-11-05 12:45:57

【问题描述】：

在我的公司，我们正在使用全新的 Abp 框架 (abp.io)。由于它是一个新框架，因此缺少很多文档，因此我们必须搜索源代码。看了这么多代码，我意识到这是他们使用的一种模式，总是出现 Providers、ProvidersManagement、DefinitionProvider 等等。我想知道这个模式是否有名字或者它只是在那里使用的东西。我不相信这是第二种选择，但我不知道。

功能模块、设置模块、权限模块都是使用这种设计模式实现的模块。

谢谢你们！

【问题讨论】：

其实很多文档并没有丢失。 :) docs.abp.io

是的，我们在这个框架上整天都在工作几个星期，我很确定它不见了。但是你不知道这个图案设计的名字吗？这将有助于更好地理解

【参考方案1】：

我想作为 ABP 框架中这些模式背后的程序员来回答这个问题；

首先，我想解释一下为什么我们要引入这些“提供者”样式模式。主要原因是可扩展性：开发人员可以通过实现提供者接口并将其注册到框架来扩展系统。这样，您无需替换或覆盖一个完整的服务来添加新的行为。

例如，PermissionChecker 服务循环通过提供程序（那些实现 IPermissionValueProvider 接口），以允许您决定当前用户是否具有请求的权限。有一些预定义的权限提供者：用户提供者，角色提供者......等。用户提供者检查当前用户是否直接授权该权限，而角色提供者检查当前用户的任何角色是否具有所需的权限。 您可以简单地创建一个新的提供程序实现，以不同的方式检查权限并允许用户执行相关操作。

在 ASP.NET Core 中也使用了类似的模式。

例如，ASP.NET Core request localization middleware 使用类似的模式来确定 Web 请求的当前区域性。有 QueryStringRequestCultureProvider、CookieRequestCultureProvider... 类试图确定来自不同来源的文化。它也是可扩展的，您可以注册新的提供者或重新订购当前的提供者。

我们在框架中一般将此类类命名为“provider”或“contributor”。

贡献者是不同的类，它们是操作的参与者。例如，对于菜单系统，有一个 IMenuContributor 接口，您可以在构建应用程序的主菜单时实现和参与（添加/删除/替换菜单项）。

该模式也类似于“Chain of Responsibility”模式。例如，IPermissionValueProvider 类似于 CoR 模式，因为每个提供者都会尝试检查当前用户是否具有操作权限。如果提供者不知道，则执行下一个提供者。

所以，我不知道确切的名称，并且在实现这些时我没有 100% 复制模式。如果这是一个新模式（我不这么认为，但是）我不擅长命名模式，让我们问问 Martin Fowler :)

顺便说一句，我们正在不断改进 ABP 框架的文档。在上一个里程碑中，我们已经完成了大部分基础文档（如 UOW、分布式事件总线……等）。最近，完全修改和扩展the startup tutorial。在接下来的里程碑中，文档也将成为重中之重。

感谢您使用 ABP 框架 :)

【讨论】：

谢谢！很高兴收到您的来信。所以如果我理解正确，如果我写一个提供者，例如设置，我是否必须建立商店？我们现在遇到这个问题。我们正在定义设置、权限、功能，我们不知道如何保存等等。我们正在寻找示例，但直到现在，我们什么也没发现。顺便说一句，这是一个很棒的框架。我们使用的是旧的 Aspnet Boilerplate，但现在我们正在迁移到 Abp（在过去 3 周内），这就是为什么我们对这个系统有如此多的怀疑。再次感谢您！

您可以将设置保存在 appsettings.json 或数据库（AbpSettings 表）或环境变量中。 docs.abp.io/en/abp/latest/Settings ABP 扩展了 ASP.NET Core 配置系统。 docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/…

随时向 GitHub 问题 (github.com/abpframework/abp/issues) 提出您的问题和问题，您也可以查看官方 Twitter 帐户和 SoF 社区。​​span>

只是为了在讨论中添加我主观的 5 美分，我认为命名不会使事情可扩展，设计可以。简单的具体名称可以更容易地推理代码。 Providers、Managers等名称含糊不清，让你更加迷失方向，我宁愿尽量避免使用它们。