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

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

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

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

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

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

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

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

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


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

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