插件应用模型

理解插件式应用中的宿主、应用上下文、模块和服务。

插件式应用由宿主程序、插件框架、插件树、应用上下文和应用模块组成。宿主负责“进程如何启动”，插件负责“能力如何进入应用”。

宿主程序

宿主程序负责启动进程并建立运行环境。它通常只包含 Program.cs、项目文件、部署脚本和基础配置。业务能力应尽量放入插件，而不是固化在宿主中。

框架提供两类常用启动入口：

这些入口会创建 .NET Host，加载宿主 .option 配置，注册插件配置源，加载插件树并初始化应用上下文。

应用上下文表示当前运行中的应用实例，对应核心库中的 IApplicationContext。它包含应用名称、版本、环境、配置、模块集合、服务提供器、事件管理器、工作器和运行时属性。

Web 宿主中的 /Application 接口会返回当前应用上下文的基本信息。

模块对应核心库中的 IApplicationModule。模块有名称、版本、程序集、服务容器和属性集合；继承 ApplicationModule<TEvents> 的模块还可以拥有自己的事件注册表。

模块名称很重要：数据访问、服务注册、日志命名和模块隔离都会使用模块名作为边界。例如数据服务默认会根据类型所在程序集的 ApplicationModuleAttribute 查找模块名，再获得对应的数据访问器。

Web 宿主中的 /Modules 接口可用于查看当前加载的模块信息。

插件可以向应用注册服务。宿主启动时会扫描宿主程序集和插件清单中的程序集，把符合服务注册约定的类型加入服务容器；插件树中的 /Workspace/Environment/Services 节点也可以把声明式构件注册为单例服务。

模块也可以拥有自己的服务域。ApplicationModule 会基于应用服务容器创建模块级服务提供器，用于隔离或命名模块内部服务。

默认插件会把常用运行时对象挂载到 /Workbench 下，例如：

这使插件之间可以通过稳定路径发现能力，而不是直接引用彼此的实现类型。

插件和模块没有自动的一一对应关系。模块对象由应用定义，并通过 /Workbench/Modules 加入应用；程序集上的 ApplicationModuleAttribute 则参与类型的模块归属。两者应使用一致的模块名。完整声明和调用见第一个业务插件。

模块容器优先解析模块服务，再回退应用共享服务，适合业务局部实现与公共基础设施协作。它不会自动建立独立进程、数据库或请求作用域，详见基础概念。

构建宿主期间先加载插件树并注册服务，随后初始化应用上下文。工作台首次构建时组织其子节点，并将 Startup 子树后置；宿主进入启动、停止阶段时打开和关闭工作台。

对象构造、应用初始化和持续工作是不同阶段。需要保持消息订阅或周期任务的组件应使用工作器管理启动、取消和释放；不要依靠构造函数启动无法停止的后台任务。

🚨 插件节点构建失败不代表所有已发生的外部操作都能回滚。组件应控制构造副作用，并实现明确的停止和清理路径。

最后更新于 1个月前