GEF的设计没有对模型部分做任何限制，也就是说，我们可以任意构造自己的模型，唯一须要保证的就是模型具有某种消息机制，以便在发生变化时能够通 知GEF（通过EditPart）。在以前的几个例子里，我们都是利用java.beans包中的PropertyChangeSupport和 PropertyChangeListener来实现消息机制的，这里将介绍一下如何让GEF利用EMF构造的模型（下载例子，可编辑.emfsubject文件，请对比之前功能相同的非EMF例子），假设你对EMF是什么已经有所了解。

EMF使用自己定义的Ecore作为元模型，在这个元模型里定义了EPackage、EClassifier、EFeature等等概念，我们要定 义的模型都是使用这些概念来定义的。同时因为ecore中的所有概念都可以用本身的概念循环定义，所以ecore又是自己的元模型，也就是元元模型。关于 ecore的详细概念，请参考EMF网站上的有关资料。

利用EMF为我们生成模型代码可以有多种方式，例如通过XML Schema、带有注释的Java接口、Rose的mdl文件以及.ecore文件等，EMF的代码生成器需要一个扩展名为.genmodel的文件提供 信息，这个文件可以通过上面说的几种方式生成，我推荐使用Omondo公司的EclipseUML插件来构造.ecore文件，该插件的免费版本可以从这里下载。（也许需要使用国外代理才能访问omondo网站）

图1 示例模型

为了节约篇幅和时间，我就不详细描述构造EMF项目的步骤了，这里主要把使用EMF与非EMF模型的区别做一个说明。图1是例子中使用的模型，其中Dimension和Point是两个外部java类型，由于EMF并不了解它们，所以定义为datatype类型。

使用两个Plugins

为了让模型与编辑器更好的分离，可以让EMF模型单独位于一个Plugin中（名为SubjectModel），而让编辑器Plugin （SubjectEditor）依赖于它。这样做的另一个好处是，当修改模型后，如果你愿意，可以很容易的删除以前生成的代码，然后全部重新生成。

EditPart中的修改

在以前我们的EditPart是实现java.beans.PropertyChangeListener接口的，当模型改用EMF实现后， EditPart应改为实现org.eclipse.emf.common.notify.Adapter接口，因为EMF的每个模型对象都是 Notifier，它维护了一个Adapter列表，可以把Adapter作为监听器加入到模型的这个列表中。

实现Adapter接口时须要实现getTarget()和setTarget()方法，target代表发出消息的那个模型对象。我的实现方式是在EditPart里维护一个Notifier类型的target变量，这两个方法分别返回和设置该变量即可。

还要实现isAdapterForType()方法，该方法返回一个布尔值，表示这个Adapter是否应响应指定类型的消息，我的实现一律为"return type.equals(getModel().getClass());"。

另外，propertyChanged()方法的名称应改为notifyChanged()方法，其实现的功能和以前是一样的，但代码有所不同，下面是NodePart中的实现，看一下就应该明白了：

public void notifyChanged(Notification notification) {
    int featureId = notification.getFeatureID(ModelPackage.class);
    switch (featureId) {
    case ModelPackage.NODE__LOCATION:
    case ModelPackage.NODE__SIZE:
        refreshVisuals();
        break;
    case ModelPackage.NODE__INCOMING_CONNECTIONS:
        refreshTargetConnections();
        break;
    case ModelPackage.NODE__OUTGOING_CONNECTIONS:
        refreshSourceConnections();
        break;
    }
}

还有active()/deactive()方法中的内容需要修改，作用还是把EditPart自己作为Adapter（不是 PropertyChangeListener了）加入模型的监听器列表，下面是SubjectPart的实现，其中eAdapters()得到监听器列 表：

public void activate() {
    super.activate();
    ((Subject)getModel().eAdapters()).add(this);
}

可以看到，我们对EditPart所做的修改实际是在两种消息机制之间的转换，如果你对以前的那套机制很熟悉的话，这里理解起来不应该有任何困难。

ElementFactory的修改

这个类的作用是根据template创建新的模型对象实例，以前的实现都是"new XXX()"这样，用了EMF以后应改为"ModelFactory.eINSTANCE.createXXX()"，EMF里的每个模型对象实例都应该是使用工厂创建的。

public Object getNewObject() {
    if (template.equals(Diagram.class))
        return ModelFactory.eINSTANCE.createDiagram();
    else if (template.equals(Subject.class))
        return ModelFactory.eINSTANCE.createSubject();
    else if (template.equals(Attribute.class))
        return ModelFactory.eINSTANCE.createAttribute();
    else if (template.equals(Connection.class))
        return ModelFactory.eINSTANCE.createConnection();
    return null;
}

使用自定义CreationFactory代替SimpleFactory

在原先的PaletteFactory里定义CreationEntry时都是指定SimpleFactory作为工厂，这个类是使用 Class.newInstance()创建新的对象实例，而用EMF作为模型后，创建实例的工作应该交给ModelFactory来完成，所以必须定义 自己的CreationFactory。（注意，示例代码里没有包含这个修改。）

处理自定义数据类型

我们的Node类里有两个非标准数据类型：Point和Dimension，要让EMF能够正确的将它们保存，必须提供序列化和反序列化它们的方 法。在EMF为我们生成的代码里，找到ModelFactoryImpl类，这里有形如convertXXXToString()和 createXXXFromString()的几个方法，分别用来序列化和反序列化这种外部数据类型。我们要把它的缺省实现改为自己的方式，下面是我对 Point的实现方式：

public String convertPointToString(EDataType eDataType, Object instanceValue) {
    Point p = (Point) instanceValue;
    return p.x + "," + p.y;
}
public Point createPointFromString(EDataType eDataType, String initialValue) {
    Point p = new Point();
    String[] values = initialValue.split(",");
    p.x = Integer.parseInt(values[0]);
    p.y = Integer.parseInt(values[1]);
    return p;
}

注意，修改后要将方法前面的@generated注释删除，这样在重新生成代码时才不会被覆盖掉。要设置使用这些类型的变量的缺省值会有点问题（例 如设置Node类的location属性的缺省值），在EMF自带的Sample Ecore Model Editor里设置它的defaultValueLiteral为"100,100"（这是我们通过convertPointToString()方法定 义的序列化形式）会报一个错，但不管它就可以了，在生成的代码里会得到这个缺省值。

保存和载入模型

EMF通过Resource管理模型数据，几个Resource放在一起称为ResourceSet。前面说过，要想正常保存模型，必须保证每个模 型对象都被包含在Resource里，当然间接包含也是可以的。比如例子这个模型，Diagram是被包含在Resource里的（创建新Diagram 时即被加入），而Diagram包含Subject，Subject包含Attribute，所以它们都在Resource里。在图1中可以看到， Diagram和Connection之间存在一对多的包含关系，这个关系的主要作用就是确保在保存模型时不会出现 DanglingHREFException，因为如果没有这个包含关系，则Connection对象不会被包含在任何Resource里。

在删除一个对象的时候，一定要保证它不再包含在Resource里，否则保存后的文件中会出现很多空元素。比较容易犯错的地方是对 Connection的处理，在删除连接的时候，只是从源节点和目标节点里删除对这个连接的引用是不够的，因为这样只是在界面上消除了两个节点间的连接 线，而这个连接对象还是包含在Diagram里的，所以还要调用从Diagram对象里删除它才对，DeleteConnectionCommand中的 代码如下：

public void execute() {
    source.getOutgoingConnections().remove(connection);
    target.getIncomingConnections().remove(connection);
    connection.getDiagram().getConnections().remove(connection);
}

当然，新建连接时也不要忘记将连接添加在Diagram对象里（代码见CreateConnectionCommand）。保存和载入模型的代码请 看SubjectEditor的init()方法和doSave()方法，都是很标准的EMF访问资源的方法，以下是载入的代码（如果是新创建的文件，则 在Resource中新建Diagram对象）：  

public void init(IEditorSite site, IEditorInput input) throws PartInitException {
    super.init(site, input);
    IFile file = ((FileEditorInput) getEditorInput()).getFile();
    URI fileURI = URI.createPlatformResourceURI(file.getFullPath().toString());
    resource = new XMIResourceImpl(fileURI); //注意要区分XMIResource和XMLResource
    try {
        resource.load(null);
        diagram = (Diagram) resource.getContents().get(0);
    } catch (IOException e) {
        diagram = ModelFactory.eINSTANCE.createDiagram();
        resource.getContents().add(diagram);
    }
}

虽然到目前为止我还没有机会体会EMF在模型交互引用方面的优势，但经过进一步的了解和在这个例子的应用，我对EMF的印象已有所改观。据我目前所知，使用EMF模型作为GEF的模型部分至少有以下几个好处：

1. 只需要定义一次模型，而不是类图、设计文档、Java代码等等好几处；
2. EMF为模型提供了完整的消息机制，不用我们手动实现了；
3. EMF提供了缺省的模型持久化功能（xmi），并且允许修改持久化方式；
4. EMF的模型便于交叉引用，因为拥有足够的元信息，等等。

此外，EMF.Edit框架能够为模型的编辑提供了很大的帮助，由于我现在对它还不熟悉，所以例子里也没有用到，今后我会修改这个例子以利用EMF.Edit。

搬家前链接：https://www.cnblogs.com/bjzhanghao/archive/2005/04/15/138447.html