I do appreciate working directly on the latest ASP.NET MVC technology these days for actual money. Extreme penny pinchers use Microsoft technology and these cheapskates tend to stay behind the latest stuff—in my experience over eight years behind. With this great opportunity comes great responsibility. So, today, let’s try to see how well a developer with salt-and-pepper hair can respond to what the kids are pounding out in Redmond:

One incorrect assumption I made when looking at ASP.NET MVC was the pessimistic view that the classic Web Forms crowd would jealously stand still. Yes, the release of ASP.NET 4 would be some sad competitive crap that would childishly ignore what the MVC team was doing. My assumption was wrong. Dan Maharry’s “ASP.NET 4.0 Part 12, Routing Helper Functions”:

With our routes defined, we can now set up hyperlinks between routes. All we need are the name of the route and the values of any route parameters. If we need to do it inline in the code (perhaps because it’s part of a data-binding operation) we can use the new <%$RouteUrl %> syntax.

My copies of my bookOne (me) could make the mistake that since the ASP.NET Page Life Cycle Overview as described by MSDN appears to not have changed (much) for years, this appearance of Routing (from the MVC world) could easily be overlooked as Routing is plugged in higher in the stack, above the ASP.NET “Page” concept (it’s an HTTP Module). Better than this MSDN piece is the award-winning CodeProject.com article, “ASP.NET Application and Page Life Cycle” by Shivprasad koirala (see also: “What is the ‘page lifecycle’ of an ASP.NET MVC page, compared to ASP.NET WebForms?” from StackOverflow.com). In attempt to not overlook here, one has this: “What’s New in ASP.NET 4 and Visual Web Developer”—and this: “URL Routing with ASP.NET 4.0” by Brij.

One terrible way to approach ASP.NET MVC for the first time is to be the guy that is “Using WebControls In ASP.NET MVC Views.” Having this very thoughtful article in my personal notes show my careful consideration for MVC beginners coming from the world of Web Forms, tempted by “the obvious.”

This MSDN article, “Events in ASP.NET Master and Content Pages,” lists no less than 17 events for ASP.NET master pages. This list clearly applies to Web Forms as any “control loading” events should not exist in ASP.NET MVC (but they do).

I need to form the habit of regularly reviewing the System.Web.UI.HtmlControls Namespace. New controls,  like HtmlLink, have been added since ASP.NET 2.0. Also, knowing how the Control.ClientID property works is also futuristic in ASP.NET land (actually, the knowing the role of ClientIDMode is the key here).

What should make ASP.NET look super cool to any developer that likes to write code is what Rob Conery writes about in “ASP.NET MVC: Securing Your Controller Actions”:

ASP.NET MVC Preview 2 introduces the new ActionFilterAttribute, which allows you to declare “Filter Attributes” for the actions on your controller. Think of these things, in essence, as OnLoad events—a bit of code that’s executed before or after your Action.

This use of attributes for a Web application goes farther, one can see this in “is [AcceptVerbs(HttpVerbs.Post)] deprecated or to be deprecated in ASP.NET MVC 2 or later?”:

No, it’s not deprecated, and it won’t be, because [AcceptVerbs] is the only way to decorate a method that accepts several (but not all) verbs.

[AcceptVerbs(HttpVerbs.Post | HttpVerbs.Put)]

It’s also the only way you can specify a verb that’s not one of the “core four”, such as those which are part of WebDAV:


Matt Hawley shows me that the use of attributes make secure patterns like the “ASP.NET MVC—Using Post, Redirect, Get Pattern” possible.

Finally, this article, “Integrating Silverlight and ASP.NET MVC,” by Tim Heuer gets me back into triple-threat mode by using JSON (with DataContractSerializer) from ASP.NET MVC to be consumed as POCOs:

Why not use System.Json and LINQ to JSON? You could absolutely. In doing so you could use your LINQ skills and get the data out of the Json stream and put it into a new object. You’ll still have to create a local class representation because Silverlight can’t bind to an anonymous type. This is the first reason I like just using the serializer. The second reason is size. I don’t know why I’m so picky, but I am. Using the DataContractSerializer method here, my app is about 7K. Adding a reference to System.Json and using those methods, my app is 27K. For me, there is no additional benefit in code for what I’m doing to add that extra size, so I choose not to. But you can…absolutely. Your application needs may be different and the size cost/benefit analysis may result in a different outcome than mine…but there, I’ve stated my reasons here.

My triple-threat (my “grand unified user interface”), by the way, means to be ASP.NET MVC, WPF and Silverlight:

GUUI: Grand Unified User Interface