实现 LinkHelper
在上个例子中，plugin.xml 中扩展了各类扩展点后，其实并不用我们写任何 Java 代码，就能够在这个 ID 为 com.example.test 的视图上完成一些 Project Explorer 已实现的操作： 例如创建项目，文件夹，文件等，这些是通过重用 navigatorContent 实现的。
另一个需要注意的地 方是，在我们实现的这个视图中，IResource 作为与 CNF 的直接接口，同时也扮演着“项目 / 文件夹 / 文 件”这个业务场景的模型角色。（这也是为什么在 LinkHelper 中 new StructedSelection(file) 能直接定 位到导航器中该节点的原因）
但是在实际的项目开发过程中，并不是每一种业务模型都像文件系统这 样易于展现。例如 Java 中的 Package 概念就需要以多个文件夹合并成一个树结点的方式展示（中间以“.” 分隔），jar 包也需要以内部解压的方式展现其内部树型结构。
所以通常情况下，业务模型会有单独 的抽象表示，并作为与 CNF 的直接接口。其优点有：
所有在 Eclipse UI 上对模型的改变，会先传递到域模型本身，然后通过 IResource 持久化到操作系统。 对模型的改变操作和改变的传递都更直接。如 图 6所示。
图 6. Eclipse 中的资源管理
同一套资源文件，通过不同的角度观察需要有不同的展现，操作及存储方式。例如一个 Java 项目在 Package Explorer 以更贴近 Java 开发的方式展现与操作，而在 Resource Explorer 则是以操作系统的视角 来展现，显示所有的文件夹及文件。这里看待资源的角度，就是构建业务模型所要考虑的事情。
接下来我们会在上一个例子的基础上，加入自己的业务模型层。虽然在文件和文件夹这个场景下，这一层 的存在意义不大，但是能供读者在解决具体的工作时借鉴。
我们仿照上个例子建立一个 custom.linkwitheditor.sample 的插件项目，但这次将自己实现大部分的功能，并加入特定的业务模型层。
首先将 view id 更改为 custom.linkwitheditor.view.myCustomNavigatorView，并添加图标。
删除 org.eclipse.ui.navigator.viewer 扩展下的 viewerActionBindin —— 这意味着在这个例子我们 并不扩展任何 action，context menus 等。
删除 org.eclipse.ui.navigator.viewer 扩展下的 viewerContentBinding —— 一会我们会创建自己实 现的 navigatorContent 与 linkHelper。