源于《EMF.Edit Framework Programmgering's Guide》

EMF.Edit里面有幾個(gè)類(lèi)比較繞，很容易被搞得暈頭轉(zhuǎn)向，所以需要澄清以下：
★AdapterFactoryContentProvider， ItemProviderAdapterFactory和ItemProviderAdapter之間的關(guān)系，ItemProviderAdapterFactory用來(lái)創(chuàng)建各種Adapter以及將各種notifier跟這些adapter關(guān)聯(lián)起來(lái)，AdapterFactoryContentProvider包裝了一個(gè)ItemProviderAdapterFactory(AdapterFactory)，它用來(lái)將JFace需要的content provider代理到item content provider上，對(duì)content provider各種方法的調(diào)用將調(diào)用到相應(yīng)的item content provider上，對(duì)org.eclipse.jface.viewers.IStructuredContentProvider的調(diào)用將代理到IStructuredItemContentProvider上，對(duì)ITreeContentProvider的調(diào)用將代理到ITreeItemContentProvider上，而對(duì)IPropertySourceProvider的調(diào)用將代理到IItemPropertySource，而ItemProviderAdapter是所有ItemProvider的基類(lèi)，AdapterFactoryLabelProvider和ItemProviderAdapter之間也存在類(lèi)似的關(guān)系

★為了顯示model內(nèi)容，我們需要使用content provider和label provider，而編輯model內(nèi)容則需要使用到editing domain，AdapterFactoryEditingDomain是一個(gè)和AdapterFactoryContentProvider、AdapterFactoryLabelProvider類(lèi)似的東東

★editing domain主要有兩個(gè)功能：一個(gè)是作為command的factory（所以它的實(shí)現(xiàn)類(lèi)是AdapterFactoryEditingDomain）；另一個(gè)對(duì)EMF Model（ResourceSet，因此提供了getResource()方法）進(jìn)行管理

★EditingDomain，AdapterFactoryEditingDomain，EditingDomainItemProvider和Command之間的關(guān)系，AdapterFactoryEditingDomain實(shí)現(xiàn)了EditingDomain接口，AdapterFactoryEditingDomain和AdapterFactoryContentProvider一樣，也是用來(lái)將EditingDomain的方法代理到EditingDomainItemProvider上去。

從一般的操作說(shuō)起，比如從一個(gè)company對(duì)象上刪除一個(gè)department對(duì)象，通常我們的做法是：
 
但是如果是使用command，則會(huì)這樣做：
 
不過(guò)這個(gè)做法有一個(gè)問(wèn)題，就是不是很通用，因?yàn)樗�有的刪除操作基本上都差不多，所以還需要繼續(xù)抽象，這時(shí)就必須引入EditingDomain.
EditingDomain的接口定義如下：

為了創(chuàng)建一個(gè)Command對(duì)象，我們需要構(gòu)造一個(gè)CommandParameter對(duì)象。在createCommand方法里面會(huì)調(diào)用指定的Command的靜態(tài)create方法來(lái)創(chuàng)建指定的Command對(duì)象，通過(guò)使用create方法，我們可以對(duì)上面的操作做進(jìn)一步的改寫(xiě)：

通過(guò)上面的改寫(xiě)，差不多實(shí)現(xiàn)了一個(gè)通用的刪除操作流程
接下來(lái)我們可以看看一個(gè)command的創(chuàng)建過(guò)程，首先是調(diào)用指定command的靜態(tài)create方法，該方法將調(diào)用EditingDomain的createCommand方法，AdapterFactoryEditingDomain作為EditingDomain的實(shí)現(xiàn)類(lèi)，又將command的創(chuàng)建過(guò)程代理到EditingDomainItemProvider上，在Itemprovider（實(shí)現(xiàn)了EditingDomainItemProvider接口）中，最終使用new創(chuàng)建指定的Command實(shí)例
我們可以采用多種方式對(duì)command定制，第一種就是復(fù)寫(xiě)generated的EditingDomainItemProvider實(shí)現(xiàn)類(lèi)的createCommand方法：

這里的RemoveDepartmentCommand 就是我們自己實(shí)現(xiàn)的刪除操作。
第二種方式就是復(fù)寫(xiě)createRemoveCommand()來(lái)實(shí)現(xiàn)定制：


通知的處理
在創(chuàng)建AdapterFactoryContentProvider的時(shí)候會(huì)將其作為一個(gè)listener注冊(cè)到AdapterFactory里面，這個(gè)AdapterFactory實(shí)現(xiàn)了IChangeNotifier接口，而AdapterFactory在創(chuàng)建每一個(gè)ItemProvider的時(shí)候又會(huì)把自己傳遞過(guò)去，從而使得AdapterFactory成為model的消息分發(fā)中心，在AdapterFactoryContentProvider又會(huì)記錄所有需要接受通知的viewer（也就是為其提供了content provider的viewer）。
當(dāng)model被改變之后，將觸發(fā)和該model相關(guān)的adapter的notifyChanged()方法（這里面的adapter就包括itemprovider），當(dāng)然這里還有一個(gè)過(guò)濾的過(guò)程，只把那些跟viewer相關(guān)的notification才會(huì)發(fā)送給viewer。為了將notification繼續(xù)傳遞，會(huì)使用ViewerNotification這樣一個(gè)對(duì)象來(lái)對(duì)notifation以及其他的信息進(jìn)行封裝，因此它繼承了Notification，除了Notification相關(guān)的信息之外，還封裝了要更新的viewer的相關(guān)元素，IViewerNotification 的定義如下：
 
對(duì)于消息的傳遞還會(huì)進(jìn)行分類(lèi)，這個(gè)是在notifyChanged這個(gè)方法里面做的，如下面的代碼：

可以看出，如果是attribute，那么會(huì)對(duì)label進(jìn)行更新，如果是reference，那么需要更新content了，否則什么都不做。fireNotifyChanged方法是在ItemProviderAdapter（就是所有ItemProvider的基類(lèi)）里面定義的，它會(huì)把notifaction傳給adapter factory，前面我們說(shuō)過(guò)adapter factory是notification的分發(fā)器，因此它會(huì)將notification發(fā)送給所有注冊(cè)的listener，我們前面也說(shuō)過(guò)AdapterFactory實(shí)現(xiàn)IChangeNotifier接口，并作為listener注冊(cè)到adapter factory中去了，因此在最后會(huì)調(diào)用adapter factory的fireNotifyChanged方法，當(dāng)然了adapter factory也會(huì)將notification代理別的對(duì)象（可能是tree或者table的content/label provider，當(dāng)然在emf中就是itemprovider了）上去，最后viewer被更新了。