框架

概述

Gaphor采用轻量级的面向服务架构设计，其功能模块被划分为一系列独立服务，包括文件管理、事件管理和撤销管理等组件。这些服务通过pyproject.toml配置文件中定义的入口点动态加载。如需深入了解架构设计，请参阅面向服务架构的详细说明。

事件驱动

Gaphor各组件通过事件机制进行通信。当发生重要变更时（例如模型元素的属性修改），系统会自动触发事件通知。应用中的其他模块只需在中央事件代理（Central Broker）注册对应类型的事件处理器（Event Handler），即可监听相关变更——无需向每个可能触发事件的元素单独注册。例如，图表项可以注册事件规则，并通过验证事件源是否与其所代表的模型元素匹配来实现精准响应。完整实现细节请参阅事件系统专题文档。

事务型处理机制（Transactional）

Gaphor采用事务处理机制，其核心原理是将所有功能操作记录为连续的事务序列。该机制通过以下方式实现：在事务开始时发送启动事件，事务结束时发送完成事件。这种设计使得（例如）撤销管理器能够持续记录历史事务日志，当用户点击撤销按钮时，系统即可回滚特定事务。

主要组件

Gaphor的初始执行主体称为Application核心模块。系统支持同时打开多个模型，每个模型均存储在独立的Session会话中。运行时仅允许一个Application实例处于激活状态，而每个会话会动态加载其专属的服务组件（定义于gaphor.services）。

核心服务组件包括：

事件管理器（event_manager）

该组件是事件调度的核心枢纽，所有涉及事件处理（包括发送与接收）的服务模块均依赖于此组件。

元素工厂 (element_factory)

数据模型本身由元素工厂（ElementFactory）维护，该服务组件主要提供三大功能：创建模型元素、元素检索、元素集合查询。

撤销管理器 (undo_manager)

最受欢迎的服务组件之一：该管理器允许用户在执行操作时偶尔出错（毕竟谁能保证永不失误呢）！

撤销管理器采用事务处理机制，其运作规则如下：事务激活原则（仅当事务处于活动状态时，用户操作才会被记录）、 提交处理（事务完成（提交）后，系统将存储新的撤销操作项）、 回滚机制（事务回滚时将直接逆向执行所有变更）。完整实现细节请参阅撤销管理器专题文档。

文件管理器 (file_manager)

模型加载与保存功能均通过该组件实现。