在（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內核實現要比上面圖形中的展現復雜不少。但基本邏輯關系的核心已經表示差不多了。

這部分內容也只能“點到即止”，畢竟本身屬于商業產品范疇。

Flex開發流程設計器的經驗之談（4）