The ASP.NET Model View Controller, Part 2: A High-Level Look at Implementation and Benefits

In the last WindowsDevPro .NET Briefing I examined some of the history behind the compelling new ASP.NET Model View Controller (MVC) paradigm. I touched upon how the MVC allows for the separation of concerns when it comes to Web development. In other words, not only can the MVC be leveraged to implement unobtrusive coding implementations, but it also lends itself insanely well to environments where lots of specialized folks (developers, designers, coders, etc.) all work on the same Web site. Now I‘ll take a high-level look at some of the MVC’s implementation details and benefits.

Fine Control over Markup
The MVC provides drastically improved control over markup within views by taking a classic approach to interleaving angle-bracket code with markup in the form of in-line expressions (<%= %>). The benefit, of course, is that this gives developers complete control of rendered markup–which is a departure from the use of traditional ASP.NET controls.

Scott Hanselman recently touched upon this in his Webforms Unplugged post where he quoted a member of the ASP.NET team pointing out that the MVC has a ‘repeater control’ – it’s called a foreach loop. Personally, I just love that approach. Yes, the MVC provides the option to use ListView or other repeaters if desired, but doing so couples your presentation with ASP.NET. Granted, the coupling isn’t severe, but would cause HTML coders or designers and client-side (only) developers to know more about the ASP.NET domain model than might be necessary. And, while a foreach loop encased in special angle brackets isn’t exactly HTML either, it’s a much easier concept for designers and HTML coders to grok–because they may be used to seeing something similar if they’ve worked with PHP, classic ASP, or even Ruby or Django.

You’ll recall from my rave in the last newsletter, one of the big benefits of the ASP.NET MVC is that you still get access to ASP.NET intrinsics such as the Response, Request, Server, and other objects. And if you’re running your applications on Microsoft IIS 7 (where ASP.NET is no longer a bolt-on step-child, but a full-fledged citizen), you’ll have even more control over the entire HTTP pipeline if that’s what you’re looking for.

But the ASP.NET team is also working on an additional set of specialized UI helpers designed specifically for creating views. Initially these helpers didn’t offer a ton of functionality, but Rob Conery has introduced a set of extensions that will be baked into subsequent versions of the MVC. The cool thing about this new suite of intrinsics is that they not only provide typical helper methods, but they can also expose information from your controllers. This means that you can use them to build dynamically generated links and other functionality on your site that won’t break if you need to tweak url routing or other aspects of your site.
Rob Conery’s additions to the UI helpers also offers a way to re-use code such as UserControls. Here’s an example:


<div> <p><%= Html.ActionLink("Series", Url.Action("List")) %></p> <p><%= ViewData.Name %></p> <%= Html.RenderUserControl("~/MyReusedCodeHere.ascx") %> </div>

With the MVC framework, you still get access to things like LoginControls or Master Pages, and where those make sense you can use them as needed. But, of course, using them can negate some of the separation of concerns benefits provided by the MVC. As such, I’m hoping that we’ll be able to build our own MVC-complaint snippets and re-use them as needed by treating them as User Controls (I’ve yet to test this to make sure it will work). The best thing about these new intrinsics, though, is that if you don’t like how they’re done or if you need different functionality, you’re free to implement your own logic by writing your own extension methods (which is the exact route that Rob Conery took).

Unit Testing
Of course, if you’ve done any meddling with the MVC to date, you’ve likely done so by paying attention to a walkthrough or some other tutorial. Invariably these walkthroughs and tutorials explicitly refer to how to use the MVC to wire up unit tests, before turning their attention to views. That’s partially, I’m sure, due to the fact that the MVC is heavily reliant upon convention – and test -driven development (TDD) is a convention Microsoft is pushing as a best practice. But it’s also because the MVC lends itself so well to testing. This is important because the MVC also allows so many people to work on the same site at once. So, for example, these different tasks can be done on the same site at the same time: infrastructure and back-end developers can work on ensuring highly optimized and efficient models, while client-side developers and designers can work on re-skinning individual pages for special events (like holidays on e-commerce sites), and site developers can change the flow of how pages all work together. With many different activities going on simultaneously, it wouldn’t be too hard for something to break–so having unit tests in place can help nip any breaking issues before they become expensive.

A Caveat
As I mentioned in the last newsletter, I’m really excited about the ASP.NET MVC. I’m impressed with how easy it has been to learn, and how much control it has given me over my markup along with the ability it has given me to create solutions that implement unobtrusive client-side behaviors and styles. But, it’s also important to point out that the MVC may not be right for all scenarios. In fact, many developers may never see the need for the MVC. In other words, it’s a tool that’s suited for specific problems. Happily, however, the MVC is not a replacement for how we currently do anything with ASP.NET. Instead it’s just a new tool that we can use as needed – which is another reason why I’m so excited about it.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.