Click here to Skip to main content
Click here to Skip to main content

WinForms Model View Presenter

, 11 Aug 2008 CPOL
Rate this:
Please Sign up or sign in to vote.
An introduction to using the MVP pattern with WinForms.

Introduction

The terms "Model View Controller" and "Model View Presenter" (MVP) are used to describe patterns that have been in use for some time in other technology areas but have recently come to the fore in the C# world.

The Model View Presenter is a derivation of the Model View Controller pattern. With modern ides such as Visual Studio inserting event handling into what we refer to as the view, it makes sense to leave them there rather than trying to implement them on a controller.

I struggled to find a simple MVP example on the web that was geared towards C# WinForms, and after reading Bill McCafferty's excellent article on MVP within ASP.NET, I decided to throw my hat into the ring.

I'm going to concentrate on the code. For a background on MVP, I suggest you try this link:

Why MVP?

The Model View Presenter pattern is designed to abstract the display of data away from the data and associated actions (e.g., saving the state). This, in theory, should make testing easier and more relevant, and remove the tight coupling typically found between data and forms within the Windows environment.

The View

The View is a user control that inherits from System.Windows.Forms. Its role in life is to display whatever data we are interested in. It contains no logic other than raising an event should the data change and any processing particular to the View such as closing itself happens. It doesn't care if anybody is listening to the event, it simply raises the event and has fulfilled its purpose. The View implements an interface that exposes fields and events that the Presenter needs to know about.

public class UserView : Form, IUserView

The Model

It is a representation of the data being manipulated. In my simple example, this a user object. The Model should implement an interface (IUserModel) that exposes fields that the Presenter will update when they change in the View.

public class UserModel : IUserModel

The Presenter

The Presenter marries the View to the Model. When first called, it updates all the properties of the View to correspond to the Model. Furthermore, it binds the View's events to methods in itself. Typically, the Presenter will update the Model based on changes in the View. Once a user has finished making changes in the View, the Model should be in sync and will be saved down correctly. The Presenter does not require an interface.

public UserPresenter(IUserModel model,IUserView view)
{
    this._model = model;
    this._view = view;
    this.SetViewPropertiesFromModel();
    this.WireUpViewEvents();
}

In my example, I use Reflection to iterate through the properties of the View / Model and update the corresponding field. Reflection is slow, but I haven't experienced any tangible slow down in any of my Windows apps yet - it would be easy to pass through a reference to the specific property being updated if speed starts to become an issue.

Putting it Together

IUserModel model = new UserModel();
IUserView view = new UserView();
new UserPresenter(model,view);
view.Show();

The code to get the ball rolling is simplicity itself, as shown above.

Testing

The example with this article includes some tests. Because our Presenter expects interfaces as opposed to concrete objects, it allows us to perform dependency injection with stubs and mocks, should we choose.

[Test]
public void DoesViewCorrespondToModel()
{
  StubView stub = new StubView();
  new UserPresenter(this._mock, stub);

In my tests, I have a StubView that implements the IUserView interface. I then instantiate a mock object representing the Model and perform testing on that. My tests check that the View shows what's in the Model and that the Model is updated when the View changes. You would, of course, include more tests in a real world project.

My stub implements Event Mocking, e.g.:

public void FireDataChanged()
{
    if (this.DataChanged != null)
    {
        this.DataChanged(null, EventArgs.Empty);
    }
}

From within my test, I simply call 'FireDataChanged' to recreate what would happen when a user changes any of the data in my View from within the application.

A Word on DataBinding

You may be wondering why I go to the trouble of implementing code in the Presenter to update the Model / View when Microsoft kindly provides us with databinding technology to bind data to Windows controls. The great thing about databinding is that it removes the need for having to write code in every Presenter to take care of the state, thus speeding the development cycle.

The problem with databinding is that it breaks our encapsulation by tightly coupling the 'View' to the data. Also, it cannot be tested from within an NUnit environment. However, one still needs to write laborious code within the Presenter to keep the Model in sync with the View. I hope that the code example I have provided you with that uses Reflection will ease this pain. Simply expose the data you require in the View and Model interfaces, and it should all be taken care of for you.

I am not a pattern zealot; you may find that given time constraints and the nature of a task you need to perform, a tightly bound view using databinding is the best option - however, I would encourage the abstraction of logic from presentation and the use of tests wherever possible.

Refactoring the Interfaces

It became apparent in the development of this article that a lot of property definitions are shared between the IView and IModel interfaces. In fact, every editable data property exposed on the Model needs to be implemented on the View; you may, therefore, like to consider implementing an additional interface called ICommonFields that is implemented by both IModel and IView. The benefit of this approach is that one only needs to add a new property to a single interface for the compiler to insist on its implementation in both the Model and the View.

Finally

Using MVP within WinForms is a learning curve, and I am keen to hear constructive criticism from anyone who thinks the example I have provided can be improved. By sharing knowledge, we all gain.

Credits

The MVP pattern has been developed by many coders over a long period of time. Martin Fowler presents that knowledge in a nice concise form on his website (link at the top of the article).

Thanks to Bill McCafferty for investing so much time in the article he wrote about MVP in ASP.NET (link at the top of article) which inspired me to submit a WinForms focused article.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

cgreen69
Software Developer (Senior)
United Kingdom United Kingdom
A .net devotee specialising in Object Orientated web development for financial institutions in Europe. When not working can normally be found at a bar within walking distance of the office.

Comments and Discussions

 
GeneralMy vote of 3 PinmemberNinad K25-Feb-14 13:54 
GeneralNice one for a starter Pinmemberernestohari7-Oct-11 0:14 
QuestionIs it really necessay to use reflection in the presenter? Pinmemberkapil Sinha11-Aug-11 21:27 
GeneralOn databinding vs. decoupling PinmemberArtem Smirnov20-Aug-08 9:07 
QuestionIUserView PinmemberMember 308313919-Jun-08 17:29 
AnswerRe: IUserView Pinmemberke4vtw10-Sep-08 17:53 
GeneralModel-View-Presenter frameworks PinmemberOleg Zhukov24-Apr-08 11:27 
QuestionWhy is your UserPresenter in the Library namespace but in the MVP folder? [modified] PinmemberDao-Huy Hua15-May-07 4:02 
I was trying to start a new project following a MVC sample and I found your code quite interesting even if it is a MVP. Seriously, it's the first time I heard about MVP and I quite like the concept after reading a bit on the subject.
 
By reading your code, I have this questionning: why is your UserPresenter in the Library namespace since it is in the MVP folder? Is it intentional?
 

-- modified at 10:41 Tuesday 15th May, 2007
GeneralArticle Update PinmemberMarkus Klieber17-Apr-07 7:34 
GeneralWhy not just use a generic presenter and pass property name Pinmembernji7812-Apr-07 14:28 
GeneralRe: Why not just use a generic presenter and pass property name Pinmembercgreen6915-Apr-07 9:13 
GeneralRe: Why not just use a generic presenter and pass property name Pinmembernji7823-Apr-07 9:04 
GeneralRe: Why not just use a generic presenter and pass property name Pinmembercgreen6924-Apr-07 10:14 
GeneralAdditional Question Pinmembercdx1135622-Dec-06 12:10 
GeneralRe: Additional Question Pinmembercgreen6923-Dec-06 5:58 
GeneralRe: Additional Question Pinmembercdx1135623-Dec-06 6:21 
GeneralRe: Additional Question Pinmembercgreen6929-Dec-06 3:14 
GeneralRe: Additional Question Pinmembercdx1135628-Dec-06 8:06 
GeneralRe: Additional Question Pinmembercgreen6929-Dec-06 3:18 
GeneralUser Custom attribute for mapping PinmemberZiming8-Dec-06 1:03 
GeneralUserPresenter adjusted PinmemberSwiss Thomas26-Aug-06 7:24 
GeneralI like your example PinmemberMaruis Marais11-Jul-06 23:57 
Questionhow funny Pinmemberc4tes7-Jul-06 5:09 
QuestionBroken link? PinmemberMarc Leger4-Jul-06 14:48 
AnswerRe: Broken link? Pinmembercgreen694-Jul-06 22:25 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.141022.2 | Last Updated 11 Aug 2008
Article Copyright 2006 by cgreen69
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid