The ASP.NET MVC framework, using the WCSF as a yardstick!

Well, right up until this morning I was planning on blogging about the similarities and differences between the patterns used by the Web Client Software Factory (WCSF) and the up and coming ASP.NET MVC Framework... and then I saw Glenn’s post linking to this great article on patterns used to structure User Interface code. Gutted. Someone has already done it, and what’s worse, they’ve done it much better and more thoroughly than what I had in mind!

Still, I think I can squeeze some mileage out of my thoughts over the past few days... J

Much of this post is my current evolving thinking on the two frameworks, and therefore if you disagree do feel free to chip in and air your views. I’m only specifically comparing against the WCSF because I feel they share many characteristics and address similar problem spaces, and so I think it leads to a good illustration of what the MVC framework might give us, and what you need to be aware of.

My thoughts are also based entirely on what information is in the public domain – I have not had any internal conversations about this, so not only does it “not necessarily represent the views of my employer”, but chances are it will be just plain wrong as CTPs start to appear... so join the debate!

In case you are not sure which patterns I’m referring to, have a quick read of the links under patterns used in the Web Client Software Factory. Specifically we’re interested in View-Presenter and Application Controller. For the MVC framework, there is an hour long video of Scott doing a demo, two posts by Scott here and here, and a good set of notes here.

So how do these WCSF patterns directly compare to those proposed in the ASP.NET Model-View-Controller framework? In the Web Client factory we have a Model (implied, although not named in View-Presenter), a View, a Presenter, and a Controller, and in the MVC framework we have a Model, View, and Controller. So surely the mapping is pretty obvious? Well, it isn’t the simple one-to-one you might think. Here’s what I’ve come up with so far;

Responsibility	WCSF MVP	ASP.NET MVC
Page flow	Controller (single)	Controller (many)
Business logic	Model	Model
Interaction with Business logic	Presenter*	Controller (many)
Presentation logic	Presenter	View (code behind)*
Presentation UI	View	View (mark-up)*

 

* Two points to note; a) you don’t necessarily have to split a View by code behind & mark-up in the MVC framework, but it seems a logical way to indicate the two roles a page can fulfil; b) many people use the Controller as a facade to the business logic in the WCSF, but the key above is that the instruction to interact with the logic is generally initiated by the Presenter calling a method on the Controller.

So what are these key differences? I’ll try to boil it down to some concrete points.

Controllers

The WCSF tends to have an Application Controller per module, but the MVC framework has many (likely to be one per group of views). So in the WCSF we might have a SalesController that handles all page flow (and potentially business logic interaction) for the Sales module. However, in the MVC framework we might have a PricingController, an InvoiceController, and a CustomerController. Page flow is not necessarily owned by any single Controller.

There may therefore be an opportunity in MVC framework applications to use something similar to an Application Controller to centralise some of the page flow; perhaps by directing all relevant requests to a single Controller Action on an Application Controller to route appropriately. More thought required I reckon!

Entry Points

The primary entry point to the WCSF framework is the View followed by the Presenter. So when the user browses to “~/DisplayProducts.aspx”, the DisplayProducts page is constructed, and the DisplayProductsPresenter is attached to it. This Presenter then drives interaction with the Controller as required to fetch Model data, decide on Page Flow, and so on.

In the MVC framework, the primary entry point is a Controller, as Controllers are URL addressable. So when the user browses to “~/Products/Display”, the ProductsController would be created, and it’s “Display” action would be invoked. This then interacts with the Model and decides which View to use to render the output.

This also drives the relationship between Views and Controllers; rather than there being one Controller for a set of Views (as I approximated above) it is really that an area of functionality has a single Controller – and that Controller may have a set of supporting Views. Therefore the Controller becomes the primary unit driving application functionality, contrary to the WCSF, in which Views are the primary unit that drives functionality.

Of course, the more obvious point to note on Entry Points is the REST-friendly URLs that the MVC framework uses by default. I don’t personally think this adds any significant benefits, but it certainly looks clean and sits with the framework well.

Views

The MVC framework has no separation of View and Presenter. The WCSF splits presentation logic into a Presenter class, and the technology-specific implementation of this into an ASPX page that implements the View definition. Conversely, in the MVC framework all logic to co-ordinate the physical rendering of a result set is contained in an ASPX page.

Perhaps an interesting point here is that the MVC framework’s Controller actually does much of the work that the WCSF’s Presenter does (in initiating interaction with the Model), and therefore MVC framework Views are expected to be significantly simpler than the View-Presenter pairing in the WCSF – pretty much just rendering mark-up and data binding expressions. This simple presentation code is roughly equivalent to what is contained in the WCSF’s View implementation (without the Presenter). So is there any point in separating further “presentation logic” in the MVC framework?

There are two reasons why a Presenter is useful in my opinion;

a) When there is real logic required to decide how to render a View.

b) When this real logic would benefit from Unit Testing.

But the approach encouraged by the MVC framework is to avoid logic in a view, and to stick to pretty straightforward data-binding etc. Instead of one complex View, you may choose to have many simpler Views. For example, if you have a list of products that can be clicked to display details of each, in the WCSF you may implement this as a single View with collapsible sections... hence there is logic to handle clicks, showing and hiding sections, retrieving data, and so on. However, in the MVC framework this would possibly be better implemented as two Views – a list View, and a details View. When the list is clicked, the request goes through to the Controller which renders the result using the details View. This is in fact likely to be necessary to avoid the View from interacting with the Model. (How does it get the individual product’s details if a View can’t interact directly with the Model? It can’t! It needs the Controller to do that first.)

ASP.NET

Something not so obvious is the way in which each framework sits in the ASP.NET runtime. Scott points out the following in this post about the MVC framework;

The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and .Master markup files as "view templates" (meaning you can easily use existing ASP.NET features like nested master pages, <%= %> snippets, declarative server controls, templates, data-binding, localization, etc). It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).

In other words, the choice to force all requests through the Controller outlaws the post-back model. In contrast, one of the goals of the WCSF was to support standard ASP.NET functionality wherever possible, to maximise the speed at which developers could get going with it, and allow it to sit well with existing frameworks. This is of course because the WCSF is an accelerator built on the framework, and the MVC framework is just that... an underlying framework.

The choice not to support post-backs in the MVC framework makes absolute sense to produce a more purist application architecture, but it does mean that developers must shift how they think about writing aspx pages.

I’ve mentioned this in a discussion about the patterns because I think it helps define component responsibilities – i.e. a View is much more lightweight in the MVC framework than a classic ASPX page might be. It moves the focus away from building WinForms-like pages to building simple rendering-only templates. I personally believe that if you make this leap, you’re more likely to avoid building monstrous pages that rely heavily on View State, and are difficult to test and maintain...

I also wonder what kind of benefits we may see by not using View State, not going through a page initialisation and load for every post-back button click...

 

The End... or rather, The Beginning

To conclude, then, my view is that these two frameworks share some common objectives and techniques, and therefore that each can potentially contribute significantly to the other. In the comments on his posts Scott implies a CTP is just around the corner, so let’s look forward to playing with it for real.

Comments

• Anonymous
  November 22, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/11/22/the-aspnet-mvc-framework-using-the-wcsf-as-a-yardstick/

• Anonymous
  November 25, 2007
  Thanks.. Which one is better? Yah. It might be a lit bit hard to say. so, which framework we should use in which situation?

• Anonymous
  November 27, 2007
  Sync; Good question, and one that I purposely avoided :-) My view is that often the biggest benefit to selecting a pattern is that you have made the selection - i.e. all developers use a common pattern, and the application has a predefined "shape". This helps prevent the nightmare that can arise when people do things in different ways in the same application. Assuming this chosen pattern meets your needs (unit testing, well defined class responsibilities, etc) then half the battle is won already. Therefore I don't think there is a massive amount to separate MVC from MVP (as patterns alone) - it may even be personal preference. Both frameworks aid with unit testing, application structure, and so on. But at the moment the WCSF is out there in the wild, and the MVC framework is not. Plus the WCSF adds much more - guidance around page flow, authorisation support, automated template code generation, bundles to help with responsive UI's, etc. Therefore at the moment I would choose to use the WCSF. [Note that this is my own personal view and not an official Microsoft statement].

• Anonymous
  December 03, 2007
  One big difference in WCSF and MVC framework is, WCSF(MVP) looks at the view, as the one that can handle input and outputs functionality using the webforms/Viewstate/postback features. A presenter doesnt not worry about handling the user inputs/interactions. With ASP.NET MVC framework, Controller is used to handle the user interactions, and so, I guess the aspx based url, and view states are no longer needed , and instead controller based clean URLs handle the user inputs. And with outputs, as with Original MVC pattern, output responsibility is with View, and ViewPage renderView method handles it. So, I think moving away from postback architecture is indeed a good sign, to maintain a MVC purity, and not making a new breed of MVC. With Original MVC Pattern, the View does maintain the direct association with model, and model indeed can be modified by the view. So, if Asp.NET MVC framework would not allow a view to modify model, that is a significant change responsibilities in MVC pattern isnt it ?

• Anonymous
  December 03, 2007
  Arun; My view is that making changes to the model is generally done in response to a user action, and therefore that responsibility lies with a controller... so there is not a deviation from the classic MVC pattern. I see views as interacting with the model primarily to render the data, which still fits with the MVC framework (model data is passed to a view to be rendered). There is a big benefit in my mind in keeping most interaction with the model (i.e. business logic calls) in the controller - as you can then switch out different views (e.g. html or xml/rss) without duplicating logic. It also enables views to be easily reused by different controllers, that may get similar data from different sources. I'd recommend reading the article I linked to - it makes some interesting comments on MVC misconceptions, though, so I see where you're coming from. One minor point I would make - although in MVP the aspx page (view) receives the user input, it is the presenter that responds to it (usually the view calls a method on the presenter, or raises an event) - the view does not directly interact with the business logic / model (other than rendering it). Hope that makes sense. As always though, how people implement these patterns is likely to vary slightly! Simon

• Anonymous
  December 04, 2007
  Thanks for your reply Simon. Yes I agree with your comments on view. "I see views as interacting with the model primarily to render the data, which still fits with the MVC framework (model data is passed to a view to be rendered)". Agreed that  does falls in place with original MVC pattern. If model data is passed to the view, then why do we need to implement multiple views in your example page with list and details. Why not the same view, that contains the list, also pull the details data from the model data thats being passed to it ? Or am i missing some implementation details here ? And yea, the reference link you provided, I got that from pnpguidance, its awesome work. It is the base to my understanding on MVP and MVC. Thanks again. Arun.

• Anonymous
  December 04, 2007
  Arun; That is a good point to make. I don't see any reason why you could not have a single view instead of two to render a master/details screen (and in some cases you want the list and the details visible at the same time so it makes more sense). I was simply using it as an example as to how it could work well to separate view responsibilities; keeping views simple and focused increases your chances of reusing them, could simplify maintenance, etc. One option here is to design the list and details sections as two User Controls. That way you can either compose them into a single screen, or render them individually (as the RenderView method can handle User Controls or whole pages). This could also work well in an AJAX scenario to partially render the sections of the screen instead of the whole page every time. Good comments! Simon

• Anonymous
  February 05, 2008
  i want to know whether it is possible to combine two techs. means i want to take advantage of a ObjectBuilder , CompositionContainer of a WCSF and I want to use MVC too so that I can select or change View  at runtime. I moved Controller to shell module but i am not geting how  to specify that controller name in Route onject in Application_Start event handler.. please help me, If u have any solution or Idea let me know ... Thanks

• Anonymous
  February 05, 2008
  Shashi - it depends what your objectives are. To use ObjectBuilder you could create a custom Controller Factory or View Factory (depending on what needs to be "built up"), and use the pure MVC framework. If you want to select the View at runtime, this is difficult in the WCSF (without using Response.Redirect etc) as it is the View that is directly URL addressable. If you wanted to add a layer of indirection here by introducing a controller, do you really want to combine the MVC and MVP patterns? I think this could be rather confusing. To answer your primary question, though, to wire in the MVC framework bits into an existing solution you need to be adding references to the assemblies, and add configuration entries for the Http Module and Http Handlers that the framework uses. I've not tried this though, so I'm not certain what the results would be. Hope that helps. Simon

• Anonymous
  February 08, 2008
  Shashi - just found the post below which may help you too! http://www.pnpguidance.net/Post/ASPNETMVCFrameworkCompositeWebApplicationBlockCWAB.aspx Simon

• Anonymous
  March 30, 2008
  The comment has been removed

• Anonymous
  March 30, 2008
  Ork; interesting comment - I'd be interested to hear more about how you feel this applies. My own personal view is that a web part model is very suited to the kind of composition required in portals - e.g. pulling in data from many different sources and coordinating some communication between parts. But for full enterprise-class systems I find that raising the abstraction to modules is beneficial. There's nothing to stop each module from being composed of smaller parts of course! Also I would say this comment mainly applies to the WCSF - the MVC framework doesn't really dictate much about composition, other than perhaps the subtle impact the relationship between controllers and views might have. Post your thoughts - I'm sure there are things I haven't considered so am keen to understand! Simon

• Anonymous
  May 30, 2008
  I have the same confusion as your article mentioned: Why 2 Asp.net patterns and what are the differences.  And why one is in WCSF and the other is not?! (Is Mircosoft endosing one over the other!?!)  By the way, your article is very good and clear comparison between WCSF and the asp.net MVC.  My understanding is clearer after reading your article.  Not sure if I am getting it right though.  I believe WCSF’s MVP pattern actual is similar to the MVC with Page Controller and the Asp.net MVC is with Front Controller since all request is funnel through by URL routing and no post back allowed where as WCSF MVP is responding to each request at a page level.

• Anonymous
  June 01, 2008
  Joe - I don't think Microsoft are endorsing one over the other; in many ways MVP was born out of the constraints of running within the existing ASP.NET pipeline and infrastructure (one of the aims of the WCSF was to fit in with existing ASP.NET development as much as possible), but the ASP.NET MVC framework actually replaces the pipeline itself, so had more scope to be radical. I think each brings something different - the WCSF brings structure to WebForms, and helps rapidly write applications using well known patterns - the MVC framework is more of a "purist" approach, catering to the crowd that do not need really rich and simple WinForm-like development, but instead are keen on maximum control of their HTML etc. Hope that helps! Also, I think you're right - MVP is a little more like MVC with Page Controller rather than MVC with Front Controller, and the ASP.NET MVC Framework does indeed use the Front Controller approach. Simon

• Anonymous
  June 10, 2008
  WCSF Application Architecture 3: Model View Presenter This article is part of a series; · WCSF Application

• Anonymous
  June 16, 2008
  Phil Haack , currently famous for working on the ASP.NET MVC Framework , has just blogged a great article

• Anonymous
  August 22, 2008
  Great post and great comments guys, really learned alot. Dino Esposito classic asp.net to the new ASP.net MVC framework this way:               ASP.NET      MVC Framwork               ---------------------------------- Request Model  PostBack     REST Data Model     Code-behind  MVC If I add WCSF to mix; do I have correct?               ASP.NET      MVC    WCSF Framework               ---------------------------------- Request Model  PostBack     REST   PostBack Data Model     Code-behind  MVC    MVP     Glad to hear from you.

• Anonymous
  August 24, 2008
  Mohamoud; yes that looks right, although I haven't seen Dino's post on that to be honest. I'm not sure about the terminology "data model"; I'd be more inclined to name it "User Interface Pattern" or something like that, as the "model" (i.e. the part of the pattern that describes the business entities and logic, and therefore which includes the "data") is part of MVC or MVP. Hope that makes sense! Simon

• Anonymous
  September 26, 2008
  Wow, sorry for all my typos and not soo good looking post above ;-) but here is Dino's article I was talking about: http://dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx and if I add WCSF to the mix:             |Classic    |    |             |ASP.NET    |MVC |WCSF -------------|-----------|----|-------- Request Model|PostBack   |REST|PostBack UI Pattern   |Code-behind|MVC |MVP tkx Simmon for the clarification ...

• Anonymous
  November 09, 2008
  This is part 3 of the WCSF Application Architecture series by Simon Ince this post explores the Model