摘要：生成的包首次被訪問時，在全局包注冊表中自動地注冊。然而，類似于資源工廠注冊表，這種顯式注冊的過程僅當(dāng)獨(dú)立運(yùn)行時被要求，在下運(yùn)行時通過擴(kuò)展指針來自動地完成。通過使用合適的資源工廠，就可以確定被產(chǎn)生的和被使用的持久化形式。

　　EMF擁有一個強(qiáng)大的模型持久化框架。通過一個高度可定制資源實(shí)現(xiàn)（resource implementation）來支持XML序列化。
　　EMF不要求持久化是基于XML或者是基于流（stream）。這個框架提供的API靈活到足以支持任何種類的存儲，甚至在不同類型的存儲中保存對象，其中包含引用。

　　EMF中持久化的基本單元叫做資源（resource），它是一個或多個與其內(nèi)容一起持久化的對象的容器。
　　EMF對象由Resource接口來進(jìn)行持久化，方法是將對象添加到資源的內(nèi)容列表中，然后調(diào)用save()方法，例子如下：

PurchaseOrder po = ...
Resource resource = ...
resource.getContents().add(po);
resource.save(null);

　　這個例子中，save()方法的參數(shù)，一個Map，如果指定了保存操作的選項(xiàng)，那么這個參數(shù)將非空（non-null）。EMF的XML資源支持的選項(xiàng)詳細(xì)介紹在15.3.3。
　　持久化的逆操作，從持久化形式中在內(nèi)存中重建活動（actiive）的對象。使用load()方法從資源的內(nèi)容列表中訪問對象：

Resource resource = ...
resource.load(null);
PurchaseOrder po = (PurchaseOrder)resource.getContents().get(0);

　　Resource接口的詳細(xì)說明在15.2.3。
　　上面的代碼帶來了以下問題：XML序列化寫到哪里？從哪里讀入？開始的時候如何獲取資源？
　　為了管理不同資源中對象之間的引用，EMF持久化框架包含了另一種接口，稱作ResourceSet，作用相當(dāng)于資源的容器。getResources()方法返回的是資源的列表，以一個集合（set）的形式。
　　通常而言，資源是由資源集合創(chuàng)建的，或者是加載的。如下：

ResourceSet resourceSet = new ResourceSetImpl();
URI uri = URI.createURI("file:/c:/data/out.epo2");
Resource resource = resourceSet.createResource(uri);

　　這里我們創(chuàng)建了一個資源集合，調(diào)用createResource()來創(chuàng)建特定的資源。這個方法的參數(shù)是URI，它被用來指定資源，在資源集合中識別出這個資源。然后，我們調(diào)用save()和load()方法，資源可以使用這個URI來決定寫出和讀入的位置。這里的URI是文件模式（file-scheme），其他支持的URI類型詳見15.2.1。
　　EMF不會向資源集合提供工廠。由用戶來決定實(shí)例化合適的實(shí)現(xiàn)。ResourceSetImpl是一個功能靈活的實(shí)現(xiàn)，通常應(yīng)該是足夠的。如果有必要的話，它也可以被擴(kuò)展以及定制。
　　傳給createResource()的URI還有另外的用途。資源集合維持（maintain）資源工廠的注冊表。為了創(chuàng)建一個資源，需要查詢（consult）它的注冊表，以根據(jù)特定的URI來獲取一個合適的工廠。這個工廠實(shí)際上創(chuàng)建了對應(yīng)的資源，并且決定對象如何被持久化。
　　注冊表根據(jù)模式（scheme）或者文件擴(kuò)展名（file extension）來選擇資源工廠。我們可以對.epo2文件擴(kuò)展名注冊EMF的默認(rèn)XMI資源工廠：

resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().
put("epo2", new XMIResourceFactoryImpl());

　　當(dāng)使用Eclipse里生成的模型時，這種注冊不是必要的，因?yàn)橄嗨频淖詴ㄟ^模型插件（model plug-in）的清單文件（manifest file）中指定的擴(kuò)展名來自動地執(zhí)行。然而，當(dāng)獨(dú)立運(yùn)行時，注冊必須被明確地執(zhí)行。否則，createResource()將無法創(chuàng)建資源并且會返回null。詳見15.2.4的Resource的嵌套工廠和Registry接口以及15.2.5的ResourceSet
　　現(xiàn)在已經(jīng)有了對持久化框架的足夠理解，來編寫簡單但有效的程序來保存采購清單：

PurchaseOrder po = createPurchaseOrder();
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().
　　put("epo2", new XMIResourceFactoryImpl());
URI uri = URI.createURI("file:/c:/data/out.epo2");
Resource resource = resourceSet.createResource(uri);
resource.getContents().add(po);
try
{
    resource.save(null);
    System.out.println("saved");
}
    catch (IOException e)
{
    System.out.println("failed to write " + uri);
}

　　這里的createPurchaseOrder()返回的是我們想要持久化的采購清單。我們可以設(shè)想它創(chuàng)建了PurchaseOrder的實(shí)例并且向其中加入一組Items，在out.epo2的最終的序列化結(jié)果如下：

　　從其持久化形式中加載采購清單的程序如下：

EPO2Package epo2Package = EPO2Package.eINSTANCE;
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().
　　put("epo2", new XMIResourceFactoryImpl());
URI uri = URI.createURI("file:/c:/data/out.epo2");
Resource resource = resourceSet.createResource(uri);
try
{
    resource.load(null);
    PurchaseOrder po = (PurchaseOrder)resource.getContents().get(0);
    System.out.println("loaded: " + po);
}
catch (IOException e)
{
    System.out.println("failed to read " + uri);
}

　　程序的第一行，訪問采購清單模型的包，另一種作用是注冊包。生成的包首次被訪問時，在全局包注冊表中自動地注冊。資源取決于能夠找到注冊的包，以反射式地實(shí)例化其描述的類。然而，類似于資源工廠注冊表，這種顯式（explicit）注冊的過程僅當(dāng)獨(dú)立運(yùn)行時被要求，在Eclipse下運(yùn)行時通過擴(kuò)展指針（extension point）來自動地完成。

　　EMF持久化框架以四個基礎(chǔ)接口為中心：Resource,ResourceSet, Resource.Factory, URIConverter。

　　URI是一個字符串，包含三個基本的部分：scheme、scheme-specific部分、可選片段。

　　這個接口用來規(guī)范化 URIs：將一個URI轉(zhuǎn)換為另一個訪問資源的URI。

　　前面已經(jīng)說過，EMF中持久化的基本單元叫做資源（resource）。盡管資源直接關(guān)系到EObjects，但是不像從第5章描述的元模型中生成的各種Ecore接口，Resource接口事實(shí)上不會來描述模型化的類。然而，它表現(xiàn)的像重要的方式之一：

public interface Resource extends Notifier
{
    int RESOURCE__RESOURCE_SET = 0;
    int RESOURCE__URI = 1;
    int RESOURCE__CONTENTS = 2;
    ...
    ResourceSet getResourceSet();
    URI getURI();
    void setURI(URI uri);
    EList getContents();
    ...
}

　　首先，資源是通知器（notifier）：多個適配器（adapter）可以被附加于一個資源，當(dāng)資源改變時，將會給適配器們發(fā)送通知。可以看到，接口定義了“虛擬特征（virtual features）”，比如resourceSet，URI和內(nèi)容，它們都被使用于通知中。
　　其次，getContents()返回的列表，描繪了資源的內(nèi)容，表現(xiàn)的十分像一個模型化的雙向的引用，相反的引用由EObject中的eResource()方法實(shí)現(xiàn)。需要注意的是，這種關(guān)系實(shí)際上并不是真正的模式化，而是概念上的，情況如下圖：

　　值得強(qiáng)調(diào)的是，當(dāng)內(nèi)容虛擬特征（contents virtual feature）期望getContents()訪問器時，其相反的訪問器的名字，eResource()，毫無疑問是非常規(guī)的（unconventional）。這是因?yàn)樗炊裱?strong>EObject中所有其他方法使用的模式，被選擇以避免與在模型化子類中生成的訪問器的名稱相沖突。還值得注意的是，對于eResource()沒有相應(yīng)的設(shè)置（set）方法，所以這個虛擬特征只能從Resource end來設(shè)置，通過將對象加入到內(nèi)容列表。
　　在URI這一節(jié)，資源默認(rèn)地包含其內(nèi)容列表中每個對象所包含的整個對象樹。這影響到eResource()的返回值。
　　內(nèi)容虛擬特征表現(xiàn)的像一個普通雙向特征，相反的是multiplicity-one。這就是說，如果一個對象已經(jīng)存在于一個資源的內(nèi)容中，將其添加到另一個則會自動地從第一個中移除。
　　此外，內(nèi)容虛擬特征展示了遏制（contaiment）語義，但僅涉及不是代理解析（proxy resolving）的模型化的遏制引用。換句話說，如果一個對象已經(jīng)存在于任一模式化的非代理解析的遏制引用，把它添加到一個資源的內(nèi)容中則會自動的將其從它的容器中移除。回顧第10章中遏制語義默認(rèn)不是代理解析。因此，它就表現(xiàn)出默認(rèn)阻止跨資源（cross-resource）遏制：一個對象只可以被直接放置在一個容器對象中，或者直接放置在一個資源內(nèi)容中，而不能兩者都放置。
　　“遏制代理”詳見13.8.2。
　　一個資源通常被一個資源集合所包含，getResourceSet()來獲取。資源在集合中通過URI來唯一標(biāo)識。通常在資源創(chuàng)建時指定URI，但是只能分別通過getURI()和setURI來訪問和設(shè)置。URI通常決定資源的持久化形式將要存貯的位置。

　　save()和load()方法將資源從活動的內(nèi)存形式復(fù)制到持久化存儲，反之亦然。每個都有兩種形式：

void save(Map options) throws IOException;
void load(Map options) throws IOException;

void save(OutputStream outputStream, Map options) throws IOException;
void load(InputStream inputStream, Map options) throws IOException;

　　EMF為資源提供了一個基礎(chǔ)類，ResourceImpl，它通過從資源集合中獲取一個URIConverter來實(shí)現(xiàn)每個單參數(shù)的方法，這個URIConverter用來打開資源的URI的輸出或輸入流，還能將流傳到對應(yīng)的雙參數(shù)方法。因此，特定子類的作用是提供有意義的，特定于存儲（storage-specific）的保存和加載實(shí)現(xiàn)。
　　通過調(diào)用unload()方法可以卸載資源。卸載會將資源中所有的對象變?yōu)?strong>代理（proxy），這樣的結(jié)果是，下次這些對象中之一從其他資源通過跨引用（cross-reference）被訪問時，資源的請求重新加載（通過EcoreUtil.resolve()）。這就可以把一個資源更新，比如自上次加載以來，底層文件（ underlying file ）發(fā)生了變化。isLoaded() 方法表明資源當(dāng)前是否被加載。
　　資源可以通過isModified()，來跟蹤對其完整內(nèi)容的任何更改，并且返回自從最近保存和加載后的變更。默認(rèn)情況下，這個特性是無效的，因?yàn)樗膶?shí)現(xiàn)昂貴而且對撤銷命令是無效的，由于撤銷看起來像變更。適當(dāng)時候，setTrackingModification() 可以使其生效。

　　URI Fragments，是資源基于ResourceImpl使用類似XPath的方式來定位對象。Resource接口定義getEObject() 方法，可以根據(jù)給出的段路徑（fragment path）來檢索對象：

Resource resource = ...
Item item = (Item)resource.getEObject("http://@orders.0/@items.2");

　　相反，也可以獲取段路徑：

Item item = ...
String fragment = resource.getURIFragment(item);

　　嵌套在Resource接口中的是Factory接口，它定義了資源如何被創(chuàng)建：

public interface Resource extends Notifier
{
    ...
    interface Factory
    {
        Resource createResource(URI uri);
        interface Descriptor
        {
            Factory createFactory();
        }
    
        interface Registry
        {
            Factory getFactory(URI uri);
            Map getProtocolToFactoryMap();
            Map getExtensionToFactoryMap();
            String DEFAULT_EXTENSION = "*";
            Registry INSTANCE = new ResourceFactoryRegistryImpl();
        }
    }
}

　　正如這個接口建議的那樣，資源工廠只是簡單地知道如何去創(chuàng)建資源的一種類型。通過使用合適的資源工廠，就可以確定被產(chǎn)生的和被使用的持久化形式。
　　嵌套在Factory中的是Registry接口，它基于特定URI，提供了選擇合適資源工廠的機(jī)制。資源工廠注冊表維護(hù)著兩個可以注冊資源工廠的map。這些map被getFactory方法咨詢，以獲取適合于給定URI的工廠。
　　ResourceFactoryRegistryImpl()，按照以下步驟來獲取資源工廠：

檢查getProtocolToFactoryMap()返回的map，使用URI的模式作為關(guān)鍵字。

如果沒有找到任何東西，檢查getExtensionToFactoryMap()返回的map，使用URI的文件擴(kuò)展名作為關(guān)鍵字。

如果仍然沒有找到，就檢查getExtensionToFactoryMap()返回的map的默認(rèn)值，使用DEFAULT_EXTENSION*作為關(guān)鍵字。

如果沒有找到相應(yīng)的匹配，調(diào)用受保護(hù)的（protected）delegatedGetFactory()方法。默認(rèn)情況下，它沒有做任何事，但可以被重寫（override）。

　　資源集合維護(hù)（maintain）著資源工廠注冊表，當(dāng)其需要創(chuàng)建資源時，就要咨詢（consult）來獲取工廠。此外，有一個可用的全局注冊表Resource.Factory.Registry.INSTANCE，它可以注冊系統(tǒng)中的所有資源集合。默認(rèn)資源集合中注冊表的實(shí)現(xiàn)重寫了delegatedGetFactory() 來委托給全局注冊表。所以僅當(dāng)根據(jù)URI的模式，在局部沒有找到合適的工廠時，才會根據(jù)文件擴(kuò)展名（file extension）來咨詢?nèi)肿员怼?br>　　在持久化框架概述中說道，在Eclipse環(huán)境下運(yùn)行時，資源工廠可以通過Eclipse的擴(kuò)展指針機(jī)制，來被自動地注冊。這樣的注冊是在全局注冊表中完成的。
　　org.eclipse.emf.ecore.xmi 插件清單文件包含以下擴(kuò)展：

　　它默認(rèn)注冊了XMIResoureFactoryImpl資源工廠實(shí)現(xiàn)。這就是為什么EMF的XMI序列化作為默認(rèn)持久化格式，以及為什么在Eclipse下運(yùn)行時沒有要求顯式的注冊。
　　如果你創(chuàng)建了自己的資源實(shí)現(xiàn)類，你需要為其創(chuàng)建工廠然后進(jìn)行注冊，以相似的方式，在你自己的插件（plug-in）中。例如，設(shè)想你已經(jīng)創(chuàng)建了自己的資源實(shí)現(xiàn)類，EPO2ResourceImpl，你想要使用它來持久化.epo2資源。為此，需要創(chuàng)建資源工廠：

public class EPO2ResourceFactoryImpl implements Resource.Factory
{
    public Resource createResource(URI uri)
    {
        return new EPO2ResourceImpl(uri);
    }
}

　　然后，你可以向plugin.xml文件中添加以下擴(kuò)展：

　　事實(shí)上，這就是在為生成器中的包選擇“資源類型（Resource Type）”時發(fā)生的事情。從以XML Schema描述的模型開始尤為重要，因?yàn)槟J(rèn)XML資源將不能讀和寫符合模式的序列化。如果注冊不能完成或者你試圖加載沒有合適文件擴(kuò)展名（file extension）的資源，Resource.load()將會拋出ClassNotFoundException。對于獨(dú)立的應(yīng)用程序，需要在代碼進(jìn)行以下等價的注冊：

Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put(
    "epo2", new EPO2ResourceFactoryImpl());

　　盡管等價，這兩個資源工廠注冊表（registration）還是有細(xì)微差別的。后者，顯式注冊，工廠的實(shí)例被創(chuàng)建并且被注冊表中的一個map直接注冊。然而，前者，基于擴(kuò)展名（extension-based）的注冊表，實(shí)際注冊的是描述符（Descriptor）。
　　描述符，另一個嵌套在Resource.Factory中的接口，在創(chuàng)建資源工廠時提供了額外的間接層（indirection）的級別（level）。在完成之前所述的4步枚舉型之后，如果注冊獲取了描述符而不是資源工廠，它將調(diào)用createFactory()并返回結(jié)果。這項(xiàng)功能使EMF能夠推遲加載特定的資源工廠類直到這個類被真正需要時。這對基于擴(kuò)展名的注冊表很重要，其發(fā)生在平臺啟動時。

　　ResourceSet是持久化API中最高級別的接口，作用相當(dāng)于資源的容器，以便允許它們之間的引用。它提供了訪問這些資源的途徑，從模型或者一組相關(guān)聯(lián)的模型中，定義了對象的上下文（context）。此外，它維護(hù)這URI轉(zhuǎn)換器，資源工廠注冊（resource factory registry），以及它自己使用的和用于資源的包注冊（package registry）
　　類似于Resource，ResourceSet并不表示模型化的類，但是它實(shí)現(xiàn)Notifier接口：

public interface ResourceSet extends Notifier
{
    int RESOURCE_SET__RESOURCES = 0;
    EList getResources();
    ...
}

　　由getResource()返回的資源的列表，構(gòu)成了它僅有的虛擬特征，表現(xiàn)得像個遏制引用（containment reference）。換句話說，資源每次只能在一個資源集合中。
　　ResourceSet為創(chuàng)建新資源提供了用戶級別（user-level）的接口。在URI那一節(jié)，我們使用最簡單的方法來實(shí)現(xiàn)這個目的，createResource()，它授權(quán)（delegate）給集合的資源工廠注冊返回的資源工廠。回顧這個注冊，是getResourceFactoryRegistry()返回的，當(dāng)它不能定位適當(dāng)?shù)馁Y源工廠時，就授權(quán)給全局資源工廠。createResource()方法在內(nèi)存中創(chuàng)建資源，并且將其添加到資源集合中，毫不費(fèi)力就能讀入和寫出持久化表示。在它盲目地創(chuàng)建資源前，也不會檢查集合是否已經(jīng)包含給出的URI的資源，這就有可能使集合處于無效狀態(tài)。
　　一個更強(qiáng)大的方法，getResource()，首先規(guī)范化給出的URI，檢查資源集合中是否有資源擁有與其匹配的規(guī)范化URI，如果有，返回這個資源。如果這個資源沒有加載，它將會被要求加載（demand-loaded），如果此方法的第二個布爾參數(shù)為真的話。如果資源沒有找到并且第二個參數(shù)為真，資源將會被要求創(chuàng)建（demand-created）和要求加載。使用getURIConverter()返回的URI 轉(zhuǎn)換器來規(guī)范化URI，使用getLoadOptions()返回的map中指定的選項(xiàng)來完成要求的加載。
　　注意的是，資源的持久化形式不會被要求創(chuàng)建。如果因?yàn)槌志没问綗o法找到而導(dǎo)致要求的加載失敗，getResource()會拋出異常。
　　所以，在持久化框架的概述中最后的例子可以被簡化。在設(shè)置資源集合和創(chuàng)建URI之后，兩行就足以創(chuàng)建資源，加載，并且訪問其中的對象：

...
Resource resource = resourceSet.getResource(uri, true);
PurchaseOrder po = (PurchaseOrder)resource.getContents().get(0);
System.out.println("loaded: " + po);

　　ResourceSet中的另一種簡便方法，getEObject()，允許我們進(jìn)一步簡化，替換獲取資源和使用單個聲明檢索其中對象的兩行：

...
PurchaseOrder po =
    (PurchaseOrder)resourceSet.getEObject(uri.appendFragment("/"),true);
...

　　getEObject()方法簡單地調(diào)用getResource()來獲取資源，必要的話進(jìn)行要求的創(chuàng)建和要求的加載，然后使用指定URI的分段（fragment）來定位和返回資源里面的對象。
　　包注冊，提供了一種手段來定位描述任一特殊包的元數(shù)據(jù)。有個全局包注冊，EPackage.Registry.INSTANCE，在其中生成的包會被自動地注冊。在其他情況下，特定語境（context-specific）的包注冊會更合適些。
　　事實(shí)上，正是資源集合提供了語境（context）。ResourceSet定義了getPackageRegistry()方法，其返回局部的（local）注冊。這個局部注冊只在局部不能找到包時，授權(quán)給全局注冊。因此，加載到給定資源集合的資源已經(jīng)檢索的包，可以在不污染全局注冊的情況下被注冊。甚至有可能，針對同一個命名空間URI，僅僅通過局部注冊一個不同的包，來重寫一個全局注冊表。
　　資源集合的主要目的是支持不同資源中對象之間的引用。特別的事，它們對要求的加載（demand-loading）和代理解析（proxy resolution）至關(guān)重要。例如，考慮資源如下序列化：

　　可以看出資源中的Supplier包含一個PurchaseOrder引用了另一個資源中Supplier中序列化的PurchaseOrder。href屬性表示的是跨文檔（cross-document）的引用，屬性的值是標(biāo)識其他資源中引用的URI*。
　　當(dāng)加載這個資源時，代理被創(chuàng)建作為previousOrder引用的目標(biāo)，指定對象的URI（例如：platform:/resource/project/sample.epo2#//@orders.1）。如果想要訪問采購清單的上個清單，可以調(diào)用 getPreviousOrder()，EcoreUtil.resolve()被調(diào)用以便解析代理（resolve proxy）。