大規模應用的開發與MVP設計模式

原文http://code.google.com/intl/zh-cn/webtoolkit/articles/mvp-architecture.html 

開發任何大型應用程式都有其困難，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）和視圖切換 

    測試 

一個包含業務對象模型，并在我們的聯系人的應用中，我們有： 

聯系人(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