Monday, 25 May 2009

Model View Presenter (MVP) Pattern

Model-View-Presenter is a user interface design pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic.

The Model is an interface defining the data to be displayed or otherwise acted upon in the user interface.

The View is an interface that displays data (the Model) and routes user commands to the Presenter to act upon that data.

The Presenter acts upon the Model and the View. It retrieves data from repositories, persists it, manipulates it, and determines how it will be displayed in the View.

The degree of logic permitted in the View varies among different implementations.

At one extreme, the View is entirely passive, forwarding all interaction operations to the Presenter. In this formulation, when a user triggers an event method of the View, it does nothing but invoke a method of the Presenter which has no parameters and no return value. The Presenter then retrieves data from the View through methods defined by the View interface. Finally, the Presenter then operates on the Model and updates the View with the results of the operation.

Other versions of Model-View-Presenter allow some latitude with respect to which class handles a particular interaction, event, or command. This is often more suitable for web-based architectures, where the View, which executes on a client's browser, may be the best place to handle a particular interaction or command.

From a layering point of view, the Presenter class might be considered as belonging to the application layer in a multilayered architectured object-oriented system with common layers but it can also be seen as a Presenter layer of its own between the Application layer and the User Interface layer.

 

Sample of MVP implementation in few steps:

1) create an interface (later in the topic will be note like view-interface ) with properties  which will contain values from webpage/form.

public interface IDataView {
string FirstName { get; }
string LastName { get; }
string Status { set; get; } }

2) make webpage/form to implement this interface

public partial class MyPage : System.Web.UI.Page,IDataView


3) implement interface members and map them to webpage/form entries (such labels, textboxes, etc.)

public string FirstName { get { return this.tbFirstName.Text; } }
public string LastName { get { return this.tbLastName.Text; } }
public string Status { set { this.lblStatus.Text = value; }
get { return this.lblStatus.Text; } }


4) create new class for presenter

public class DataPresenter { }


5) declare a variable of view-interface type (created at point 1), variable value will be initialized through constructor

public class DataPresenter
{
private IDataView _view;
}


6) create/extend constructor with input parameter of view-interface type

public class DataPresenter
{
private IDataView _view;
public DataPresenter(IDataView view) { _view = view; }
}


7) create public method(s) for manipulate with view

public class DataPresenter
{
private IDataView _view;
public DataPresenter(IDataView view) { _view = view; }
public void SaveData() {
_view.Status = string.Format("FirstName={0}; LastName={1}",
_view.FirstName, _view.LastName);
}
}


8) in webpage/form create an instance of the presenter, constructor requires input value of view-interface type. Because the webpage/form already implements an view-interface, input value for constructor will be this.

private DataPresenter _presenter;

protected void Page_Load(object sender, EventArgs e)
{
_presenter = new DataPresenter(this);
}


9) now you can calling presenter’s method(s) from the events etc. If the presenter method change view’s data you’ll get back updated data automatically based on mapping from point 3.

protected void Page_Load(object sender, EventArgs e)
{
_presenter = new DataPresenter(this);
btnSave.Click += delegate { _presenter.SaveData(); };
}


In my sample I called the SaveData method on  _presenter presenter.

No comments: