企业官网建设流程全解析

MITK 工程四大组结构分析

Applications / CppMicroServices / Modules / Plugins 的作用与关系

概述

MITK 工程在解决方案中分为四个组。先说明一点：在源码树中CppMicroServices
实际位于Modules/CppMicroServices/，但因为它是独立的第三方项目
（有自己的 LICENSE、README、CMake 体系），在 VS 解决方案里被单列为一个组。

一、CppMicroServices —— 服务注册中枢（最底层）

位置：Modules/CppMicroServices/（core/module、core/service、core/util）

C++ 版的 OSGi 微服务框架（来自独立开源项目）。提供"接口注册/发现"机制：
模块 A 注册一个服务接口的实现，模块 B 只凭接口类型就能查到它，双方零编译依赖。

// Modules/Core/src/Interactions/mitkDisplayActionEventBroadcast.cpp: L48 —— 实际用法m_ServiceRegistration=us::GetModuleContext()->RegisterService<InteractionEventObserver>(this,props);

MITK 内部大量能力靠它解耦：

• IO 读写器（各文件格式的 Reader/Writer 以服务注册）
• 渲染服务、交互事件观察者（InteractionEventObserver）
• DataStorage 服务（IDataStorageService）

二、Modules —— 算法与功能库（核心主体，77 个）

纯 C++ 动态库，每个用mitk_create_module()声明（见Modules/Core/CMakeLists.txt）。

内部分层

模块声明示例（Modules/Core/CMakeLists.txt）

mitk_create_module( DEPENDS PUBLIC MitkLog CppMicroServices # ← Module 依赖服务总线 PACKAGE_DEPENDS PUBLIC Boost nlohmann_json ITK|IOImageBase+... VTK|FiltersTexture+... # ← 第三方库按需引组件 )

关键特征

Module 不依赖 BlueBerry/Plugins——可以脱离工作台在任何 Qt/命令行程序里单独使用
（CoreCmdApps就是纯命令行用法）。这是 MITK "算法可独立复用"的设计基石。

三、Plugins —— 工作台功能插件（UI 组装层，82 个）

CTK/BlueBerry 插件，每个用mitk_create_plugin()声明，带plugin.xml
（贡献 View/Editor/Perspective 扩展）。

两大类

插件声明示例（org.mitk.gui.qt.datamanager）

# CMakeLists.txt —— 编译期：链接 Module mitk_create_plugin( EXPORT_DIRECTIVE MITK_QT_DATAMANAGER EXPORTED_INCLUDE_SUFFIXES src MODULE_DEPENDS MitkQtWidgetsExt) # ← 依赖 Modules 层

# manifest_headers.cmake —— 运行期：插件间依赖 set(Plugin-Name "MITK Data Manager") set(Require-Plugin org.mitk.gui.qt.application org.mitk.gui.qt.common)

角色

Plugin 是 Module 与工作台之间的"胶水"：把 Module 里的控件/算法包装成
View/Editor 插入 Workbench。两套依赖声明各司其职：

• MODULE_DEPENDS—— 编译期链接哪些 Module 库
• Require-Plugin—— 运行期需要哪些其他插件先激活

四、Applications —— 可执行程序（最顶层，仅 2 个）

Applications/AppList.cmake：

set(MITK_APPS Workbench^^MITK_BUILD_APP_Workbench^^MitkWorkbench # 默认 ON FlowBench^^MITK_BUILD_APP_FlowBench^^MitkFlowBench # 默认 OFF )

main() 有多薄（Applications/Workbench/MitkWorkbench.cpp）

intmain(intargc,char**argv){mitk::BaseApplicationapp(argc,argv);// 来自 Modules/AppUtilapp.setSingleMode(true);app.setApplicationName("MITK Workbench");app.setOrganizationName("DKFZ");...returnapp.run();// 其余全交给插件框架}

真正内容全部由插件提供，App 只在target_libraries.cmake里声明装载哪些插件：

# Applications/Workbench/target_libraries.cmake set(target_libraries org_blueberry_ui_qt # 工作台框架 org_mitk_gui_qt_extapplication # 扩展应用外壳（传递拉入其余插件） )

CTK 的依赖图工具（DGraph，见 AppList.cmake 注释）会自动解析插件传递依赖，
把需要的全部插件启用。

五、依赖关系（严格单向，自下而上）

规则

1. 依赖只能向下：App → Plugin → Module → CppMicroServices；
   反向不允许——Module 永远不知道 Plugin 的存在。
2. 横向解耦靠两套机制：
   • Module 之间：CppMicroServices 服务（编译期只依赖接口）
   • Plugin 之间：BlueBerry 扩展点（plugin.xml 声明，运行期装配）
3. 分层收益：
   • 算法（Modules）可以不带 GUI 复用到第三方程序
   • 界面（Plugins）可按需增删，不改一行核心代码
   • 换一个应用（Applications）只是换一份插件清单

小结

CppMicroServices 是总线，Modules 是引擎和零件，
Plugins 是装在工作台上的仪表盘，Applications 只是点火钥匙。

关键文件索引