Geeks With Blogs


Google My Blog

Catch me at: The List!

My InstallScript Utility Belt My Amazon Wishlist
My Standard Disclaimer

Chris G. Williams Beware: I mix tech and personal interests here.
So, I've been avoiding this whole ASP.NET Model View Controller (MVC pattern) thing for a while. That it, until late last week, when it landed squarely in my lap. We're going to be using it at a client, so I better get familiar with it. 

I had read a few articles online about the Model View Presenter (MVP pattern), and those read like stereo instructions, only not as exciting. So, as you can probably imagine, I was less than enthused at having to pick up YANT*.

Fortunately, fate was smiling upon me this weekend. The latest issue of MSDN plopped on my doorstep Saturday morning contained an article by Chris Tavares on ASP.NET MVC. In fact, I'd go so far as to say it was a pretty good article. (Don't get me wrong, this is HIGH HIGH praise, because as much as I may love Microsoft, I've always found MSDN Magazine to be one of the least readable of the techy magazines I subscribe to. Let's just say, I find it a little dry.")

The article begins by identifying what you need to download to get started, and while unfortunately it was ALL IN C# (sigh), it was easy enough to convert on the fly to VB.NET... although I did have trouble with one part (setting up additional entries to the route table in the Global.Asax.Vb file... just because I'm not familiar with the syntax.)

With that out of the way, and 3 days left on my trial install of VS2008 Pro, I dived in. It took me about 45 minutes to work through everything in the article, and while I definitely have a new appreciation for ASP.NET MVC, I'm still a long way off from taking over the world.

Armed with my newfound knowledge, I started doing some more googling (sorry Live Search) and taking a look at the documentation I find.  Apparently, there is something in the Ruby on Rails world beyond the MVC and MVP patterns. It's a hybrid between MVC and MVP, called appropriately enough MVC+P.

Interesting...  my first thought was something like this:  Why? (ok, more like... Why the HELL are we doing THAT??)  It seemed redundant to me... Aren't Views and Presenters basically the same thing? (Go easy on me, I'm a newb to all of this.)

So, I read some more. I think I get it...  (correct me if I'm wrong.) Based on what I read, MVC+P works like this (slightly paraphrased): 

The Presenters form a layer between the Models and the Views. Each View depends on the Presenter, which is aware of an appropriate Model for its data source. In this scenario, a Presenter can talk to different Models for different pieces of data. The View gets passed to the Presenter as an interface. The Presenter can then be exercised and tested by any View interface implementation.

So basically, it makes testing easier?

I mean, we already get separation of concerns in the MVC pattern (our UI is no longer tightly coupled to, well, anything) and we don't map to template files anymore either (MVC maps us to Controller classes that handle their own requests) so what does adding Presenter really give us?

From what I can tell, the Presenter in MVC+P acts as a broker. The key is that while each View depends on the Presenter, the Presenter does not depend on any one Model for it's data. So depending on the request it gets from the View, it can make a call to whichever Model it needs to.  Also, this has the added benefit of making a thin View even thinner, by letting the Presenter do more of the heavy lifting.

I think I got it... time to go write some more code.  If I'm way off base (who me??) feel free to tell me...
Posted on Monday, March 10, 2008 12:01 PM General Interest | Back to top

Comments on this post: ASP.NET MVC+P

Requesting Gravatar...
The main diff between MVC and MVP that I've seen is that in MVC your model knows about the domain, where in MVP the presenter acts as a pure facade to it.

However, that's taking it in a simplistic view. In a web app I'm doing right now, we're implementing MVC (without the new framework, just in regular webforms), but I'm adding a DTO (Data Transfer Object) which acts as the "common" model that all three pieces know about. I could take it one step further and have my domain model sit behind my DAL (or have a service layer that sits in front of my DAL/Repository and Domain), which would still give the same effect. long story short, yeah I *think* you got it. ;)

Left by D'Arcy from Winnipeg on Mar 10, 2008 12:50 PM

Your comment:
 (will show your gravatar)

Copyright © Chris G. Williams | Powered by: