ALT.NET Headline, MVC for ASP.NET is coming


Today at the ALT.NET Conference, ScottGu let out a big secret, MVC for ASP.NET is on it’s way. No I wasn’t there, though with Twitter you don’t have to be 😉 You can read more about it here, here and here and on Brad’s Twitter feed here. Over in p&p we’ve actually known about what was coming for a while, but like all good secrets at Microsoft, we weren’t allowed to kiss and tell. More than knowing about it, a few guys on my team most notably Chris Tavares, and Michael Puleio actually participated in the design.


Initially there was an ounce of skepticism, but so far from what we’ve heard, we are all impressed with the direction. Many Kudos to Scott Guthrie for making a monumental change to the platform at a time when the community has been asking for it.


For those that don’t know about MVC, MVC stands for Model View Controller. If didn’t know about MVC, then it’s a pattern that’s not new and has been around for almost 30 years having originated out of the Smalltalk community. There are also many successful implementations on the web including the Struts framework, Java Swing, Tapestry and more recently Ruby on Rails and Monorail for ASP.NET.


MVC (Courtesy of Martin Fowler)


image


Essentially MVC shifts the focus from the Page to the Controller. The Controller is responsible for serving up the right Page (View) based on an Action. Controllers and actions are exposed through URLs. In other words in MVC the request hits the Controller first before any Page has been instantiated. This is very different than the current ASP.NET model in which the Page is the entry point. Another key aspect of MVC is the Model. The Model represents the domain object. The View renders directly off of the model which it has an inherent reference to. The same Model can be reused across multiple views.


So what’s the big deal?



  • Views are simplelight. In MVC views are simply UI renderings and do not contain logicother than rendering logic. If your familiar with MVP you may say “Isn’t that the same as MVP”. No, in MVP you manually delegate down calls to the Presenter. Also you have the control model where you drop server-side controls on to the page and listen to events in the code behind. In MVC, there are no server controls, and no code behind. The framework calls the controller, and you don’t delegate anything.

  • Everything is pluggable. In the ASP.NET implementation of MVC, you can replace a piece if you don’t like it. All methods are virtual meaning you can override with your own implementations. You can even change the view renderer. This means if you want to use NVelocity, Brail, etc you can. Or if you like, you can write your own.

  • Controllers are reusable. In MVP, the Presenter is scoped to a particular view. In MVC, Controllers can and are usually used across multiple views. For example CRUD operations for creating, editing and deleting an Order can be all off of the same Controller.

  • Decoupling. The Controller decouples the Model from the View. This means you can make changes in the Controller without having to touch the View and vice-versa. Combined with Dependency Injection (which the new framework supports) means further decoupling in that everything gets wired up at runtime. This opens the door for testability.

  • Testability. I mentioned it above, but I’ll reiterate it here. All the decoupling allows a lot of mocking to go on, which fits in nicely with unit testing.

Does this mean you need to radically change the way you develop with ASP.NET? Well Yes and No. Yes if you want to take advantage of the new framework, No if you don’t. The new framework is an add on to ASP.NET and not a replacement. This means the ball is in your court, and no one is forcing you to do anything.


What about WCSF? Well the simple answer is at this point in time we don’t have one 🙂 However as we are committed to aligning to the platform, we will be working closely with the MVC.NET guys to see what a WCSF / MVC world looks like. Many of the capabilities we provide in WCSF like Dependency Injection, Separation of logic, appear to be inherent in MVC. As this is an add on to ASP.NET and not a replacement, I can assure you this is not another case of Acropolis. WCSF will be here for a long time.


In summary with MVC your web applications should be more maintainable, more reusable, and more testable. I know, I know you’ve heard such promises before. However in this case MVC has stood the test of time so that in itself is certainly telling.


I am sure it’s going to be an interesting ride, stay tuned!

Comments (8)

  1. Après avoir annoncé la disponibilité du code source du Framework .NET, Scott Guthrie continue dans sa

  2. Part Time Australian says:

    What exactly do you mean by

    "I can assure you this is not another case of Acropolis".

  3. @Part Time Australian

    Meaning with Acropolis we announced that we had no intention at this team of doing another release of SCSF. In the case of MVC for ASP.NET, it won’t affect our plans on future releases of WCSF other than the fact that we will look at how to support MVC within.

  4. I usually just share these news through my shared readings feed, but this one is too big the let it pass

  5. I want it! NOW! ;~)

    When can I get my hands on it? I’ve been banging my head against these issues for months now and it really feels pointless to continue my own path if you guys are supporting this soon.

  6. Polly says:

    Any information on how one would go about migrating code based on the UIP application block to this new MVC implementation?

  7. @Polly

    We don’t have any migration guidance from UIP to MVC, though we will keep this in mind. Our current migration path for customers using UIP is to use the PageFlow ApplicatioN Block which is included within WCSF 1.1. This leverages Windows Workflow Foundation to all you to declaratively define navigation graphs within a site.