Flex开发流程设计器的经验之谈（3）

昨天说了WorkbenchPart、EditorPart、ViewPart，以及为什么需要做这样的抽象，今天就先跳出这么细粒度的讲解，今天先来看看整个Flow Designer的整体结构。反正说写博客，想到哪里说道哪里。

在讲正题之前，如果阅读过前两篇的，可以先看看：
Flex开发流程设计器的经验只谈（1）：连接>>>

Flex开发流程设计器的经验只谈（2）：连接>>>

整个Flow Designer的粗的架构如下：

其中“Flex GEF”是真正的Kernel，其内部的对象关系很多来源于Eclipse GEF的设计思路，当然远比Eclipse GEF要简易很多。

Flex GEF—— 实现最基础的Editor接口，维护Model-EditPart-Figure之间的关系。

Flex GEF4G—— 在Flex GEF之上实现一套专门针对Graphical的扩展

Flex GEF4P—— 在Flex GEF4G之上，实现一套专门针对通用Process描述的扩展。这样Flow Designer则可以将更多的精力和实现放置于专门针对特定Flow视图展示上。在第一篇介绍的内容中，只所以可以显示两种视图，原因就在此。

Flex UI View—— 对ViewPart的实现，由于Flex本身基类中对图形化组件支持的非常好了，所有基本上没有太复杂的扩展。

Model—— 实现对Model接口的声明，以及对Model变更的时候做Notifer响应机制的实现。
Flex Extention—— 扩展了一些Flex Controls和Containers做，来辅助视图显示。

一下是没啥用处的个人随感废话，大可不必看：

说实话，这套构架完全没有任何新颖的地方，也没啥特别的。我只是把它按照Eclipse GEF这种思路，在Flex（或者说用ActionScript)简易化的实现了一把。

只是一方面我之前对Eclipse GEF并不熟——虽然网上有很多介绍“如何基于Eclipse GEF开发”文档和教程，但真正从“底层”来阐述GEF原理，分析GEF内部机制和真正实现原理的文章太少。所以不得不一遍遍的翻Eclips GEF/UI方面的源码，来寻找正确的设计源泉。

另外，目前这套Flex GEF框架还不是很成熟和稳定。基本架构是在去年12月底构建完结的，也可以说初步实现。前些日子（今年2月初）在用其去实现上层一个小模块的时候，发现原有的一些设计还有很不足的地方，又做了一些地方的重构和调整。也许还需要更多的Case去检验其完整性。