GEF的MVC结构

 

GEF有一个比较大的优势，就是提供了标准的MVC三层架构。它的设计目的是尽量减少模型和视图之间的依赖。用户可以根据自己的需要创建模型，然后还可以根据自己的需要创建视图，中间通过控制器就可以将模型和视图联系起来，从而实现模型的可视化编辑。

那么GEF是如何实现三层mvc架构的呢？

先看下图：

由上图可知，GEF的模型层为model层，控制层为EditPart，视图层为Figures层。

模型层：用户可以根据业务的需要定制自己需要的模型，而不用受eclipse的限制或者其他框架的限制，而是可以自己自主的定义模型的定义。它只与EditPart有关系，而不用知道Figures层的存在。为了能让控制器知道模型的变化，应该把控制器作为事件监听者注册在模型中，当模型发生变化时，就触发相应的事件给控制器，后者负责通知各个视图进行更新。

Figures层：只负责图形的显示，目前基本上所有的图形都是基于Draw2D实现的。所以所有的Figures都是IFigure， 视图除了模型的显示功能以外，还要提供编辑功能、回显（Feedback）、工具提示（ToolTip）等等。 它也只是与EditPart打交道。当控制器传递model过来后，它就肩负着显示图形的使命，并且还要提供编辑功能，回显功能。

控制层：即EditPart层，控制器是模型层和图形层的桥梁。它一方面监听模型层的变化，把模型层的变化传给Figures层，另Figures层显示模型，一方面将Figures层的编辑结果反映到模型层上。

大致工作方式：每个模型都有一个model，对应的就会有一个Editpart类和一个Figure类（此Figure类会继承于IFigure）。EditPartViewer接受用户的操作，例如节点的选择、新增或删除等等，每个节点都对应一个EditPart对象，这个对象有一组按操作Role分开的EditPolicy，每个EditPolicy会对应一些Command对象，Command最终对模型进行直接修改。用户的操作转换为Request分配给适当的EditPolicy，由后者创建适当的Command来修改模型，这些Command会保留在EditDomain（专门用于维护EditPartViewer、Command等信息的对象，一般每个Editor对应唯一一个该对象）的命令堆栈里，用于实现撤消/重做功能（这里其实用到的是command命令模式），关于command命令模式请看博客：GEF中命令模式。

关于模型，Editpart，Figure的创建用到了工厂方法模式，这个具体的博客以后会写。