文章目录
- 1. 先看全局：三个对象分别负责什么
- 2. Solution：整套方案在内存中的总入口
- Solution 里最值得先看的数据
- 它还负责调度整套流程
- 3. ProjectInfo 与 Project：一个描述流程，一个让流程跑起来
- 4. Project 的三组核心数据
- 4.1 ModuleList：流程真正的执行清单
- 4.2 ModuleDic：用空间换时间的模块索引
- 4.3 OutputMap：插件之间传递数据的中转站
- 5. 为什么 Project 绝不是“纯数据类”
- 6. 创建一个流程时，框架究竟做了什么
- 7. 从源码还能看到哪些设计信号
- 信号一：方案级状态比较集中
- 信号二：流程配置与运行状态混在同一个对象里
- 信号三：名称在流程执行中具有业务意义
- 信号四：当前单例实现不是线程安全单例
- 8. 读完这一篇，至少要能回答这 5 个问题
- 9. 一张图总结
VM 框架数据结构系列（01）——方案层与流程层
第一次打开一个体量较大的 WPF 项目，最容易犯的错就是从界面事件一路追进细节：窗口、按钮、插件、线程越看越多，却始终不知道“整套工程的数据到底放在哪里”。
分析 VM 框架，可以先抓住两个类：
Solution：管理整套方案的全局上下文；Project：承载并执行一个具体流程。
它们构成了框架最上层的骨架。后续要理解模块、变量、数据流和持久化，都绕不开这组关系。
本文不逐行翻译源码，而是回答 4 个更实用的问题：
- 一套方案怎样容纳多个流程？
- 当前流程怎样被选中和运行？
- 流程里的模块与输出数据放在哪里？
- 为什么
Project不是一个普通的数据实体？
先给结论：
Solution决定“这套工程里有什么”，Project决定“其中一条流程怎样跑”。
