OBSOLETE

MVP Design

With the release of GWT 2.1, there are some classes and tools to aide with the development of a web application using the MVP (Model View Presenter) design pattern. The following link explains the MVP design pattern and the various ways the GWT framework helps implementing MVP based web application: http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html

...

• Option A: There is a bi-directional relationship between the Presenter and the View (each has a reference to an interface of the other). In this case, the view listens to its own component events, and notifies the presenter when action needs to be taken, like adding a new message. Likewise the Presenter directly notifies the View when data changes occur.
  • Pros:
    • Easy to implement and read.
    • The presenter does not need to know anything about how the view meets it requirements, making it loosely coupled to the view implementation.
    • Works well with UiBinder, so the UI can be built with an XML configuration file, rather than code.
    • Very easy to have multiple implementation of the view (like a mobile view and browser view).

• • Cons:
    • Some of the business logic is in the view. For example, only enable a delete button if one or more items are selected in the
      list. It is more difficult to test view business logic in unit testsIt has bi-directional dependencies.

• Option B: The Presenter has a reference to the View, but the View knows nothing about the Presenter. With this option, the View provides hooks for the Presenter to listen the components in the View. The View does not listen to any components its own components.
  • Pros:
    • It is possible to create Views with zero business logic making it easier to testDependencies go in only one direction.
  • Cons:
    • The Presenter must micro-manage the View, making the View interface very verbose.
    • The Presenter is tightly coupled to View implementation, making it difficult to create alternate View.

...