FunkyKB: ASP.NET MVC (and Web Forms) Topics

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:

[AcceptVerbs("LOCK")]

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

One thought on “FunkyKB: ASP.NET MVC (and Web Forms) Topics

  1. Hmm… Nice to be known as the guy with the ‘terrible approach’ :)

    In any case, I agree that using WebForms in MVC isn’t a good idea. I mention that those posts are mainly to see if it was possible to make it happen. Even still, a lot of developers have invested a lot of time into WebControls – being able to port some work over might be a nice way to convert more people to MVC.

    I’m also not entirely convinced that WebControls can’t serve a purpose with MVC. I think a lot of people view MVC as an ‘all MVC server code blocks or nothing’ solution, which I disagree with. I’ve done posts about other ways WebControls can be used to accomplish something that wouldn’t be possible with the way MVC renders content. (Stylesheets: http://somewebguy.wordpress.com/2010/04/06/adding-stylesheets-scripts-in-asp-net-mvc2/ )

    Another good example is the differences between ‘RenderPartial’ or WebControl. Both inherit from UserControl, both are .ascx files in your project – But one of them you can create properties for (with intellisense in your page) and bind your model to them.

    I realize my view on the matter isn’t mainstream so I don’t really expect to convince a lot of people to agree with me, but ASP.NET *is* WebForms no matter how much you use server side code blocks for rendering. That said, why not take advantage of the tools that are available?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>