透过GXT 的 Mail 示例，学习GXT 的 MVC结构

 

基于GWT 的 GXT UI框架 （即EXT-GWT，ExtJs的GWT版）不但提供了企业级的丰富GWT UI组件，而且实现了MVC结构，使得GXT的可用性大大加强。通过Dispatcher，Events，View，Controller，及它的BeanModel模型很好的完成了MVC各组件的职责解耦与相互通信。下面是通过GXT 自带的Mail示例，对其MVC实现的一个概要管窺。

 

1.Dispatcher是整个MVC结构的调度中心，是发号命令的指挥所，是Controller的容器，所有的Controller必须通过Dispacther的add()函数向这个指挥所报到，以便由它统一调度安排，即进行消息的路由。

 

2.每个Controller在报到前，通常得告诉Dispather这个调度中心，我能做什么，我对什么样的命令有责任，或者说对什么样的事件感兴趣。这通常是在Controller的构造函数中，通过registerEventTypes ()函数注册自己关心的事件，以便调度中心发出相应的指令、或者说什么事件发生时，去执行相应的任务。这个可以通过Mail示例中，各Controller子类的构造函数清晰的看到。

 

3.各Controller完成报到后，即进入待命状态，随时接受调度中心的安排，以完成任务。

 

4.当用户或系统向指挥所下达一条指令时，如Mail示例初始化时，通过向Dispatcher发出了Login的登录指令，调度中心即Dispacther，随即在内部对各报到的Controller进行逐一询问，都有谁要参与这次任务，找到一个后即刻下达任务，再询问下一个Controller。注意，这里任务的下达，是要讲先来后到的，即谁先报到谁就先领受任务。至于自己在接到任务后，都要干什么，这个是下一步紧接要描述的。

 

5.各Controller接到调度中心的任务，准备执行前，调度中心得检查你准备好没有，没有准备好，即会让Controller通过自己的initialize() 函数进行出发前的准备工作，即进行必要的初始化。

 

6.Controller完成准备工作后，随即根据指令，开始自己执行相应的任务。这是通过各Controller的handleEvent ()来领命受命的。

 

7.到这一步，Dispacther调度中心就完成了任务的下达指令，和各Controller任务的执行流程，即完成了消息的路由。各Controller完成任务后，通过forwardToView （），向调度中心提交任务完成报告，即进行View视图的呈现。当然，各Controller 在执行任务的过程中，也可以请求Dispatcher的协助，通过Dispatcher.forwardEvent ()来进行消息的路由。

 

8.View在接到Controller生成任务报告时，也可能要进行必要的准备工作，如视图的构建、布局等，这是通过View的initialize () 来进行的。当然，也不一定要在这里进行初始化，视图也可以根据Controller下达的不同命令来执行不同的视图构造，初始化等，因此在完成初始化后，视图的handleEvent () 紧接着也随即执行。

 

9.以上即是比较典型的GXT MVC各成员的互动流。值得注意的是，联系各组件的核心是AppEvent，即事件。在事件的来回传递中，可以在其中夹带执行任务时，可能所必须的各种数据信息。这一点可以在Mail示例的MailController接到用户点击了主界面左侧的某个邮箱时，完成到服务器抓取数据后，需要MailView来展现邮件的onViewMailItems () 函数清楚的看到，它在导航到MailView视图前，包装了一个事件，并往里面塞入了从服务器抓取的所有邮件Beans，然后传给MailView视图。

 

一直以来，认为GXT很好的实践了一些经典的设计模式，MVC在这里堪称一个经典的轻量级MVC结构，甚至还有超越，比如Controller还支持一个父子的层级结构。如果想要体会更多的精彩，你可以深入它的源代码上下求索一番

 

你可以在这里 发现一篇更为详尽的GXT Mail示例的全面介绍英文。there is also another article

 

最新更新（2010-01-03）：

从分析GXT的MVC模式到研究新近GWT开发阵营非常流行的MVP模式，收获良多，GWT2.0的几个关键核心概念的推出，个人猜测GWT开发模式会发生很大的变化，包括第三方UI组件库必须付出很大的努力，方能跟上GWT2.0的步伐，尤其是GWT2.0中UIBinder将带来组件开发的全新模式，由此打算放弃GXT，至少在GXT从内部全面支持GWT的架构体系之前不打算采用，从搜集的信息看来，GXT3.0可能会达到此目标，不过，感觉是遥遥无期的事情。

 

PS:在此文的回复中，我有提到GWT官方文档中有一篇关于MVP的介绍，对该文提及的源码在一次无意的搜索中找到，现在上传上来，有需要的同学可以下载

评论

5 楼 flashcloud 2009-12-28  

我在这里发现一篇关于Google I/O 2009中，GWT Best Practice的视频演讲英文整理稿。
更为精彩的是，已经有人基于此一MVP核心概念，作出一个GWT官方例子的MVP版，更有甚者，有人替换了该例子的服务端IOC容器-Google的guice，采用Spring这一流行的IOC作为服务端容器。
小提示：这几个网站都被和掉了，我用TOR + Firefox才打开的。

4 楼 flashcloud 2009-12-24  

to Kymair:
感谢你的提议，最近一直在深入研究MVP模式，它确实在GWT的开发过程中，对单元测试有了一个质的提升，同时使耦合降至更低。职责更加清楚。在这里发现一篇GWT官方文档对MVP及单元测试的较为详尽的介绍：Large scale application development and MVP。
不过，一直为一个问题困扰，GXT(Ext GWT)，SmartGWT等一些优秀的第三方GWT的UI组件库由于其架构体系偏离GWT的官方接口标准，与MVP的无缝插接，至少现在是需要付出非常大的努力才行。不过，已经有人开始这一动作了：mvp4g。
不知Kymair对此是否有继续深入的研究。

3 楼 Kymair 2009-12-06  

GXT的MVC一点也不经典……
具体可以看这篇文章
http://blog.gerardin.info/archives/40

推荐博主看一下Google I/O 2009里面Google Adwords的开发者关于GWT Best Practice的演讲，在Youtube上可以找到

2 楼 flashcloud 2009-11-23  

正在考察不采用GWT RPC，而使用REST + JSON来返回数据的可行性方案，不知道有没有朋友有这方面的实践经验。

1 楼 jazzy 2009-11-23  

周末看了GWT和GXT，在看Mail的时候，注意到了GXT的这种基于event的mvc。当时就觉得很舒适，极大地解除了View之间的耦合。