开发任何大型应用程序都有其困难，GWT应用程序也不例外。多个开发人员同时工作在同一个代码库中，维护同一模块的功能，很有可能把代码搞乱。为了增强代码的可维护性，我们在项目引进了设计模式来分离各部分的职责。
在多种设计模式可供选择：Presentation-abstraction-control, Model-view-controller, Model-view-presenter等等。虽然每种模式有它的好处，我们发现当开发GWT应用程序时，MVP设计模式是首选的，理由有两个。 首先MV设计模式，就像其他的设计模式一样，通过解藕方式来允许多个开发人员同时工作；其次，这种模式使我们能够减少我们使用 GWTTestCase ，由于它依赖于浏览器，而且，利用MVP设计模式后，我们大部分的代码，只需写轻量级（快速）JRE的测试用例（不需要浏览器）。
这个模式的核心就是把功能分成组件，对于GWT应用，有一个明确的重点就是要求使 视图 尽可能简单，以减少我们使用GWTTestCase测试时对浏览器依赖以及减少花在测试上的总时间。
一旦你了解这个设计模式这背后的原理。开发一个MVP的应用程序可能变得直接和容易。为了帮助解释这些概念，我们将使用一个简单的联系人的应用作为一个实例。这个应用程序将允许用户查看，编辑和添加联系人到存储在服务器上的联系人列表中。
首先，我们将引入以下组件:
Model
View
Presenter
AppController
然后我们将研究这些组件如何交互的，交互过程可分为
绑定 presenter 与view
事件(Events) 与事件总线 (event bus)
历史管理（History）和视图切换
测试
Model
一个包含业务对象模型，并在我们的联系人的应用中，我们有：
联系人(Contact)：一个联系人列表中的一个对象。 为简单起见，这个对象只包含了一个名字，姓氏和电子邮件地址。 在更复杂的应用，这个对象将有更多的属性。
联系人明细(ContactDetails)：仅包含唯一标识符和显示名称。
View
一个视图包含应用程序的所有的UI组件。 这包括任何表格，标签，按钮，文本框等，视图（view）负责UI的布局，对模型（model）并不了解。 就是说视图不知道它正在显示联系人的信息，只是知道它有，例如，3标签，3个TextBox和2个按钮，垂直的组织在一起。视图之间的转换是通过表现层（Presenter）中的历史（History）记录来管理。
在我们的联系人应用程序的视图有：
ContactsView
EditContactView
EditContactView用于添加新的联系人，以及编辑现有的联系人。
Presenter
表现层(Presenter)包括我们联系人应用的所有逻辑，有历史管理、视图转换、以及通过RPC与服务端的数据同步。作为一个通用的原则，每个视图（view）有一个对应的Presenter，用来驱动视图，处理这个视图中的部件产生的事件。
在我们的例子中，有如下的Presenter
ContactsPresenter
EditContactPresenter
EditContactPresenter 可以新增联系人以及编辑存在的联系人。
AppController
对于一些不属于任何视图，而是一些应用层面的逻辑，我们引入了一个AppController 组件，这个组件包含历史管理和视图转换。视图转换直接和历史管理相关，下面将针详细介绍。
本文摘自：
http://whalm2005.javaeye.com/blog/849770