in Search

Do you Twitter? Follow us @CodeBetter

David Hayden [MVP C#]

.NET Tutorials, Patterns, and Practices

MVP in ASP.NET - Development with Just the Promise of a View

Jeremy is talking about the differences in the various flavors of MVP as well as MVC in his recent post. Yesterday I was thinking about the same thing while developing another project in ASP.NET using the Model-View-Presenter Pattern.

One of the things that I noticed during development is that I started developing the web application with no actual view, just a promise of a view as defined by a contract, say IAddCustomerView. As I started running through user stories I didn't even consider creating a web page or user control, but instead started at the Presenter and used a mocking tool to be the view in the UI. During the process I got this "high" because I was able to stick with user stories and not have to change gears and deal with visual goo while I was on a roll.

I just started with simple expectations. Something as simple as if a customer name is left blank that the web page ( view ) is notified of such a tragedy. Could be as simple as:

[Test]

public void EmptyCustomerNameShouldCauseInvalidCustomerMessage()

{

MockRepository mocks = new MockRepository();

IAddCustomerView mockView = mocks.CreateMock<IAddCustomerView>();

AddCustomerPresenter presenter = new AddCustomerPresenter(mockView);

Expect.Call(mockView.CustomerName).Return(string.Empty);

Expect.Call(mockView.CustomerTitle).Return("Jester");

Expect.Call(mockView.PhoneNumber).Return("555-1212");

mockView.Message = "Invalid Customer...";

mocks.ReplayAll();

presenter.onAddCustomer();

mocks.VerifyAll();

}

with say a view contract of:

public interface IAddCustomerView

{

string CustomerName { get; }

string CustomerTitle { get; }

string PhoneNumber { get; }

string Message { set; }

}

The test just confirms that if the view provides an empty customer name that the view is notified with an "Invalid Customer..." message. No actual view was developed or harmed while implementing the expectation and I could move on to additional expectations Smile

This felt good because I was able to start development immediately without a view, and I wasn't tied to the schedule of the designer who was doing the UI for the customer. Although I would rather do Model-View-Controller, the addition of the Presenter Class in Model-View-Presenter felt good in that I was able to get as close to the view as possible without actually having one. For the first time, I believe I actually started experiencing the value of the MVP Pattern during development which was quite eeeeery. Of course, it was Halloween after all.

Published Nov 01 2007, 11:37 AM by David Hayden

Comments

Brad Mead said:

Nice... you've helped me along the path a bit too... (i.e. Forget UI for a moment and get it working from the presenter... this ties well with my evolving beginners understand of TDD)

# November 1, 2007 12:51 PM

Craig Bowes said:

Maybe you could point me in the right direction.

i'd like to get started w/ MVP or something like it because we are about to start one or two large, business logic intensive applications. In at least one of these applicationas, i can foresee the UI changing later on from an asp.net/ajax UI to a silverlight UI. I'd like to be able to resue more code from the presentation layer which is something MVP is supposed to help with. This way, I don't have to rewrite everything at that layer.

Craig

# November 1, 2007 4:06 PM

Joseph Gutierrez said:

If you connect your view to your presenter via the observer pattern (Presenter First) then the view doesn't even care who receives the event. Your presenter then becomes nothing more than event handler code, passing data from view to model or model to view. I always save the view for last. I'll even forgo the implementation of the view until last. I'll create stubs that implement the view and load my triads up in a context, then run integration scripts to activate events on the stubs. This helps me make sure I've wired up the presenters correctly. Cool Post!

# November 1, 2007 11:27 PM

rams said:

David,

Thank you for explaining the concept so simply with the help of your example. This article hones the concept of leveraging the MVP pattern much more elegantly than a bunch of academically leaning articles I have read.

Thanks

# November 2, 2007 8:07 AM

David Hayden said:

Craig,

I started using the MVP Pattern after experiencing the Web Client Software Factory. You certainly don't have to use the factory, but they do have a reference implementation, talk about MVP in the documentation, as well as have some guidance recipes around it for productivity that you may find useful at:

http:///www.codeplex.com/websf/

Many of the examples are starting to use more AJAX and web services, so it may give you some pointers on how to leverage the same code from both web pages, web services, smart clients, etc.

# November 2, 2007 11:37 AM

David Hayden said:

Hi Joseph,

I have used the event-based approach as well. Thanks for mentioning it as my choice of delegating to the presenter class is only one way to handle view-presenter communication.

I didn't really find any strong advantages or disadvantages using either approach so I pretty much just use delegation. If you know of any reasons to use one over the other I would love to hear them.

Thanks.

# November 2, 2007 11:41 AM

Neil said:

This is our experience too. Once we realised that we don't want to have references to System.Web.UI in the Presenter or MockView, things became much clearer (and simpler). Your example above uses strings, so presumably you just trust that whoever implements the real page or user control will use a Label (or whatever asp.net control) and set <UI.Control>.Text?

# November 3, 2007 5:52 AM

Tales from the SharpSide said:

Links from the Sharpside [11.03.07]

# November 3, 2007 6:21 PM

David Hayden said:

Neil,

Correct. I essentially agree to a view contract with the UI designer and trust that he/she does the UI appropriately. We don't have to use strings for the contract, however, I just used them in the example. We could pass a class back and forth, which would make a less chatty and brittle interface if I decide to change, remove, or add fields later on.

# November 4, 2007 9:43 AM

Neil said:

Currently, we have decided to use a fake label for testing:

public class FakeLabel : Lableable

{

private string text;

public String Text

get{return text;}

set {text = value;}

}

public interface Lableable

{

get{;}

set{;}

}

This seems to do the job for us by ensuring the real view implements something that has a <control>.Text property raher than leaving it for the code behind to realise it needs to set <control>.Text from the string.

We use a fake or mock that implements IListSource. That allows Repeaters, GridViews etc to be chosen by the designer.

It is early days yet, so I am interested to see how far we can go with this approach. I am still unsure of how own design staff can work with all of this. They use Dreamweaver of course.

# November 4, 2007 3:15 PM