在（3）中，简要介绍了整个Flex版设计器的整体架构，那么今天就进入比较细粒度的Flex GEF的内核看看。
既然名称中有“GEF”，那么肯定会与Eclipse GEF的设计会有所类似，事实上，本身就是借鉴GEF的设计思想和对象概念模型，只是做了改造和简化。
如下图所示。
其最基本的核心在于“IModel、IEditPart、IFigure”，这构成了MVC的核心对象模型。
IModel的变更会通知IEditPart这个控制器，由控制器刷新IFigure。—— 不过此处并没有采用EMF那种对象结构：EMF在底层对Model的所有属性变更都做了监听，任何变更都会引发Notifor操作，从而利用监听器来处理notification。在我最初的设计中，原本也想这么操作的，不过后来摒弃这个思路。如果在底层再引入一个类似EMF的框架，会再引入大量的基类，无形中增大了最终flash文件的大小。所以，此处虽然也支持Notifor操作，但是都是“外围显示主动通知Notifor”的方式，而且抛弃了Notification这一层。—— 这样的结果就是，我在command中，并不是非常彻底的只操作Model，或多或少都会会显示引发对EditPart的处理操作。（这是一个很“拖泥带水”的实现方式，但是处理方式要简化很多，而且节省了很多底层代码，缩减了flash文件）。
当然，每一个Editor都会维持一个属于其自己的EditDomain，用于记录在当前操作空间的一些对象，比如“commands”、“那些对象被选中”、“Figure或Model与EditPart的快速索引”等等。
另外，每个Editor都会由一个Viewer来，定义当前显示方式。同时，利用EditPartFactory、ModelFactory、FigureFactory来创建相应对象。上层业务层真正需要实现不同的Factory（已经包括相应的model、editpart、figure），这样就可以很容易快速实现不同“视图展现模式”。—— 外围大量的扩展代码都是在这个地方。
当然，这里面有一个“Figure”概念。早在（1）中，就已经简单提过，Figure并不是Flex中的概念，只是用用于“声明这是一个GEF中的图形”而已。（ 注：这个Figure的处理很有技巧性，处于商业产品的限制，我无法更多的在这里做详细解释，大家只能自己揣摩了 ）
当然，真正的Flex GEF内核实现要比上面图形中的展现复杂不少。但基本逻辑关系的核心已经表示差不多了。
这部分内容也只能“点到即止”，毕竟本身属于商业产品范畴。
