logo
  • Jobs
  • About Me
  • Contact
  • Home
« Avoiding Failure
Comment Spam, Part II »

Model View Presenter

Posted January 11th, 2005 by Matt Berther

Martin Fowler has introduced several new enterprise patterns for his new book. The one that has intrigued me the most so far is Model View Presenter.

Model View Presenter separates the behaviour of a presentation from the view while allowing the view to receive user events.

Take the code below as an example:

public interface IMyView
{
    string FirstName { get; set; }
    string LastName { get; set; }
 
    string FullName { get; set; }
}
 
public class MyPage1 : System.Web.UI.Page, IMyView
{
    IMyView.FirstName
    {
        get { return txtFirstName.Text; }
        set { txtFirstName.Text = value; }
    }
 
    IMyView.LastName
    {
        get { return txtLastName.Text; }
        set { txtLastName.Text = value; }
    }
 
    IMyView.FullName
    {
        get { return fullNameLabel.Text = value; }
        set { fullNameLabel.Text = value; }
    }
 
    void btnButton_Click(object sender, EventArgs e)
    {
        // this would probably be a class level declaration
        // so that it is not recreated every time. In this trivial example,
        // it doesnt matter
        MyPresenter presenter = new MyPresenter(this);
        presenter.CreateFullName();
    }
}
 
public class MyPresenter
{
    private IMyView view;
 
    public MyPresenter(IMyView view)
    {
        this.view = view;
    }
 
    public void CreateFullName()
    {
        view.FullName = String.Format("{0} {1}", view.FirstName, view.LastName);
    }
}

At this point, the Concrete View contains all the UI widgets. Since we do not have any UI components in our View interface, this would make the view and the presenter truly portable.

All of our business logic is contained in the Presenter. We could take the Presenter and the IMyView interface and create a winforms application just as easily. Even better, since we’ve completely abstracted the view and made it as dumb as possible, we could easily test our application as well.

Since we’re using Constructor Injection (Type 3 Inversion of Control), we can easily create a MockView that derives from IMyView that merely contains accessor variables for the properties. Our test then passes the MockView object into the MyPresenter object. With that, we’re able to completely test the presenter.

I’m looking forward to investigating this pattern more, and hope to show a working sample using this pattern soon.

This entry was posted on Tuesday, January 11th, 2005 at 12:56 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

David Starr
January 14th, 2005

Martin Fowler did not introduce this pattern as his did he? This is a fairly old pattern taught in design architecture classes in CS programs everywhere.

http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLD,GGLD:2004-29,GGLD:en&q=model+controller+pattern

Matt Berther
January 14th, 2005

No, he’s not. You’re describing MVC (Model View Controller).

From the link:

Classic MVC doesn’t work well with modern rich client tools because they design things so that the view handles all the user events such as mouse and keyboard clicks. In Model View Presenter the view continues to handle these, but then immediately delegates these to the presenter. The presenter then decides what to do with the event, communicating with the domain and the data in the view’s controls.

The difference between MVP and class MVC is that in MVC the Controller changes the Model or the View and the View gets data from the Model. The model also updates the view when data changes.

Using MVP, the View only communicates with the Presenter. The presenter then communicates with both the View and the Model.

sadek
November 8th, 2006

what about a command within the model view presenter?
http://mragile.spaces.live.com/blog/

SonnyM
February 20th, 2007

Great article,

Implementation gives a simple understanding :),

At first I had doubts with this pattern, but after gaining a deeper understanding of it I’ve realised how it enforces separation of view from model(controller). makes the view dumber which is a good thing.

Cheers
Sonny M

Mr. Rask
June 28th, 2007

Instead of calling methods on the presenter from the view, i find that defining events in the view interface makes for a more clean cut (the view no longer has to have knowledge of the presenter).

I the add the view to the presenter via constructor injection:

ICustomerView customerView = new CustomerForm();
CustomerPresenter customerPresenter = new CustomerPresenter(customerView);

Inside the presenter i then hook up the events that the presenter needs from the view.. (e.g. “Save”)

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
-->

Social
  • mattberther on twitter
Syndication
Archives
  • August 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003
  • November 2003
  • October 2003
  • September 2003
  • August 2003
  • July 2003
  • June 2003
  • May 2003
  • April 2003
  • March 2003
Jobs
mattberther.com © 2003 - 2008