Saying that MVP is a kind of design pattern is incorrect. Actually it is an architecture pattern. MVP, as well as joint, as User Interface (UI) business logic that divides each other. (Separation of Concerns.) In a button click event the host within a procedure to identify and UI to do this is often not correct. The UI can change continuously. Or you want to implement your web or windows application to a mobile.

It is difficult to do that as soon as possible. And ususally it is not very successfull. But by using the Separation of Concerns approach it is possible. Model View Presenter (MVP) is based on this philosophy. What is Model View Presenter?

What is Model View Presenter?

The main objective is to separate the business logic from the UI. Let's see this with a diagram.

ModelViewPresenter_1.png

The difference from a MVC (Model-View-Controller) structure is that MVP is a page control. What does this mean? The presenter controls the page or form when the web page is loaded. By Presenter is activating in the Presenter's constructor. Because the IView interface in the View (UI) has been implemented at the page. The Page or a form is derived from this interface. The Presenter has an IView property in the Constructor. Because of this, an object from Presenter is created in the UI side and if the View class is connected to this interface, the control switches to the Presenter page.

Code

Let's talk about code.

 public class DomainView: IDomainView{
    private IDomainPresenter domainPresenter;    public DomainView()
    {
        this.domainPresenter = new ConcreteDomainPresenter(this);
    }
}

ViewImplementation in application is provided in the example above. The Presenter constructor is called by implementing IDomainView which helps the Presenter to get control of the form.

Model

Model is a domain area that can be the same as a database table model. Also include CRUD events. The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.

Code

 public class Product
    {
        public string Name { get; set; }
        public string Model { get; set; }
        public string Type { get; set; }
        public double StokPrice { get; set; }
        public DateTime StokAddedDate { get; set; }

public void Save()
{
dbase client = new Sql();
ListDictionary ld = new ListDictionary();
ld.Add("@name", Name);
ld.Add("@model", Model);
ld.Add("@type", Type);
ld.Add("@stokPrice", StokPrice);
ld.Add("@stokAddedDate", StokAddedDate);
client.UpdateSql(WebConfigurationManager.AppSettings["myKey"].ToString(), "[proc_AddProduct]", ld);
}

}


Presenter

The Presenter must notify the Model but the model doesn't have any knowledge of the Presenter. The Presenter is the envoy to provide communication between the Model and View. Also the Presenter has a role to play in the CRUD event. The Presenter passes into View elements (properties, Events etc.) by using a constructor which has an interface is called IProductEditorView. All of the communications has been transmitted over IProductEditorView. The View class implements from IProductEditorView. The Presenter calls View by IProductEditorView.

Code

public interface IProductEditorView
    {
string ProductName { get; }
        string ProductModel { get; }
        string Type { get; }
        double StokPrice { get; }
        DateTime StokAddedDate { get; }
        event EventHandler<EventArgs> Save;
 }

The above interface calls from the Presenter Constructor.

Code

public class ProductEditorPresenter
    {
        private IProductEditorView mView;
        public ProductEditorPresenter(IProductEditorView view)
        {
            this.mView = view;
            this.Initialize();
        }
        private void Initialize()
        {
            this.mView.Save += new EventHandler<EventArgs>(mView_Save);
        }
        private void mView_Save(object sender, EventArgs e)
        {
            try
            {
                Product product = new Product();
                product.Name = mView.ProductName;
                product.Model = mView.ProductModel;
                product.Type = mView.Type;
                product.StokPrice = mView.StokPrice;
                product.StokAddedDate = mView.StokAddedDate;
                product.Save();

}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
throw;
}
}
}

View

ModelViewPresenter_2.png

The view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data. The View doesn't have any knowledge of the Model. The View has a relation with the Presenter using IproductEditorView. The Presenter Class instance is initialized in the View's OnInit event. Communication between the Presenter and the View starts at this point. Look at the following code. The View implements IproductEditorView.

Code

 public partial class _Default : System.Web.UI.Page, IProductEditorView
    {
        private ProductEditorPresenter mPresenter;

protected override void OnInit(EventArgs e)
{
base.OnInit(e);
this.mPresenter = new ProductEditorPresenter(this);
}
protected void Page_Load(object sender, EventArgs e)
{

}

protected void SaveProcess(object sender, EventArgs e)
{
if (this.Save != null)
this.Save(this, EventArgs.Empty);
}

#region IProductEditorView Members

public string ProductModel
{
get { return txtProductModel.Text; }
}

public string ProductName
{
get { return txtProductName.Text; }
}

public DateTime StokAddedDate
{
get { return DateTime.Parse(txtDate.Text); }
}

public double StokPrice
{
get { return Convert.ToDouble(txtStokPrice.Text); }
}

public string Type
{
get { return txtProductType.Text; }
}

public event EventHandler<EventArgs> Save;

#endregion
 }
}

Two primary variations

Passive View: The View is as dumb as possible and contains nearly no logic. The Presenter is a middle-man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In the Passive View there is no direct data binding, instead the View exposes setter properties which the Presenter uses to set the data. All state is managed in the Presenter and not the View.

Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.

Differences between MVC and MVP

MVP

MVC

References

http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference

http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

http://www.codeproject.com/Articles/42967/Model-View-Presenter-via-NET