昨天說了 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去檢驗其完整性。

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