Are you excited about ASP.NET MVC?

curious As I observe the reactions across the Internets about the forthcoming ASP.NET MVC framework, there seem to be two general reactions: those that can't wait to get their hands on the MVC framework and see this release as long over due, and those that don't see the point of rocking the WebForms boat. When I first heard about the new framework, I must admit that I fell in to the later camp. What would a new MVC framework let me do that I can't do (with all my years of experience and 3rd party tools) faster with WebForms?

Not satisfied to ignore the issue, I dug deeper and tried to learn all there is to know about the yet to be released framework. Along the way I learned some very cool facts about ASP.NET MVC that have moved me from one camp to the other. I'm now very excited about trying ASP.NET MVC and looking forward to the first preview bits that should be available in a couple of weeks. But I know there are many of you out there that still don't see the point of ASP.NET MVC, so I decided to provide the answers to some the questions I had before doing my research to help you see why ASP.NET MVC might be worth adopting. My goal is not to convince you that ASP.NET MVC or WebForms is better, but simply to help you, the overloaded programmer that is still trying to fully grasp WPF, WF, WCF, XAML, and Silverlight, quickly understand some key facts about the new ASP.NET tool.

My personal FAQS

How hard is it going to be to learn ASP.NET MVC?

There is no two ways about this aspect of ASP.NET MVC: it will have a learning curve that will require some time to master. ASP.NET MVC is a radical shift from the "traditional" ASP.NET method of page programming, where code and markup are (relatively) tightly coupled. Instead, "controller" classes will handle all of the processing logic and be wired to any number of "views" that render markup. Gone are the concepts of page postback (to itself, at least), code behind/beside, and (this is a big one) the page lifecycle.

But before you think this is the end of world and abandon interest in ASP.NET MVC, remember back to the days when you transitioned from ASP classic to ASP.NET. At that time, the strange world of "WebForms" seemed bizarre, with "code behind" pages, this crazy thing called "ViewState", and a complex "page lifecycle" to learn. "How could I leave my inline coding and top-to-bottom page evaluation to learn this fancy ASP.NET?" we thought. It didn't take long, though, for ASP developers to quickly understand the benefits ASP.NET brings to the table and flock to the new technology. So it may be again with WebForms and ASP.NET MVC.

While a lot is changing on the processing end of ASP.NET, many familiar concepts will continue to exist in MVC. Things like masterpages, themes, UserControls, ServerControls, and services like Membership and Profile will all be present and accounted for. Even ASPX pages survive as a valid way to create MVC Views. Some changes will clearly be required for ServerContorls (especially complex ServerControls like those that Telerik makes) to work in the new page lifecycle-less environment, but for the programmer using the controls these changes should be relatively transparent. The key change in MVC vs. WebForms is where the framework processes its logic and renders its markup. Not how.

Besides bringing MVC to ASP.NET, what's so special about ASP.NET MVC?

One of the biggest advantages of the ASP.NET MVC framework is that it will make ASP.NET applications much easier to test. Unit testing ASP.NET applications today can be a challenge since many objects in an application require the HTTP context to function properly. You can get around that requirement by implementing mock objects, but that is especially difficult when the objects needing the mocking are not based on interfaces. In ASP.NET MVC, all core APIs and contracts are interfaced so you can easily build your mock objects and run fast tests against your ASP.NET code. Hopefully some of this benefit can be back-ported to WebForms in the future.

Also in the realm of testing, the ASP.NET MVC framework does a much better job of enforcing clean separation of processing logic from UI markup. This is an inherent benefit of most MVC frameworks, so it should go without saying for ASP.NET MVC. Nonetheless, it will take what "code behind/beside" tried to do for the separation of logic and markup in WebForms to the next level and help ASP.NET developers enforce clean separation.

Beyond testing improvements, the MVC framework is also introducing some very interesting URL processing models for ASP.NET developers. In the past, if you wanted to use a URL like "/products/beverages/beer" you would need a URL rewriter (at the IIS level, in fact) to make it happen. Under the hood, the URL would really be something like "/products/detail.aspx?cat=1&id=20" and you'd use Request.QueryString to extract the values. With ASP.NET MVC, clean URLs are the norm and they have tight integration with the MVC controllers. For example, if an ASP.NET MVC app has the URL "/Products/Details/5", it automatically execute the "Details" method in the "Products" controller and passes the value "5" to the method as an input parameter. Pretty cool stuff!

Is it an either or decision: WebForms or ASP.NET MVC?

No. You can have an application that uses both WebForms and ASP.NET MVC. ASP.NET MVC is not replacing WebForms; it is simply another tool in the ASP.NET developer's toolbox to help them develop (and test) quickly and efficiently. But remember the age old truth: just because you can doesn't mean you should. I'd suggest you avoid the Frankenstein blended apps (like mixed ASP classic/ASP.NET apps) if you can.

What about my 3rd party UI components? Are they still usable?

Maybe, but in most cases UI controls (like those that Telerik makes) will probably have to be "tweaked" for the MVC environment. Operations that currently postback to the page (like sorting a RadGrid, for instance) will not work in the lifecycle-less MVC approach. But have no fear, Telerik is eagerly awaiting the preview bits for ASP.NET MVC so we can run our tests and determine exactly what you'll need to have the same level of productivity in an MVC environment (as I am sure other component vendors are doing, too).

Okay, this MVC thing sounds interesting. Can I download some bits?

Not yet, but according to a recent statement from Scott Guthrie, the first preview bits for the MVC framework should be available within the next couple of weeks. That means by the week of December 10th, you should be able to download the ASP.NET MVC framework and get your hands dirty with the approach to ASP.NET. Consider it an early Christmas present. It's up to you whether you'll consider it a lump of coal or beautiful diamond.

16 Comments

  • finally! I'd also be interested in learning how I can implement this for transactions that span over multiple pages.

  • I don't think I've ever seen so much talk and tutorials for an unreleased piece of code.

  • @Alex- I know what you mean. I am very eager (as are many) to actually get some hands-on time with the bits to form "real" opinions about the implementation of ASP.NET MVC. On paper, at least, it looks promising.

    ASP.NET MVC is about as big (in my opinion) as the shift from ASP classic to ASP.NET. I bet if we looked back at history, there was quite a bit of chatter about ASP.NET before any bits were released. This pre-release chatter is probably on par with previous releases of this scale.

    -Todd

  • Good post.

    Honestly, while I’m really excited I have to admit (as you guys sort of hinted at above) that the constant articles by people who do have it are really putting a damper on my enthusiasm.

    It’s like being a kid where your friend has the cool toy you want and every day he comes to school and tells you stories of all the fun he’s having with the toy. Eventually it’ll get to the point where you just don’t want to hear about it anymore.

    That’s almost where I’m at. One post with code (like Scott Guthrie’s authoritative entry) is fine and even if the internal guys wanted to make a bunch of posts like this one it would be fine but these constant code centric post are just annoying me. I’m glad they’re excited and I’m glad they want to post their experimentation just embargo the posts until you’ve given us the ability to follow along and then post them publicly.

    P.S. While I’m being cranky I’d also like to say that you guys should already have whatever they have. If I can’t use my UI controls that’s a big issue and they should be giving you as much lead time as is possible to make sure that doesn't happen.

  • Todd, if you have ever looked what people are doing outside MS camp, you'll see it's almost totally MVC. Look at RoR, multiple Java Frameworks, PHP Frameworks, Python Frameworks, and the list goes on. Most of them are implementations of a front controller based MVC framework. This is exacly the case with ASP.NET MVC.

    MS should have delivered this in a first place, if you ask me. I didn't need Web Forms for anything, and still after many years of web forms development I feel that I don't need them for anything.

    So the shift is a little bit backwards in terms of ASP.NET Web Forms vs. ASP.NET MVC. Back to more traditional, more simple and more transparent programming and application design. ASP.NET MVC can be defined as "ASP without spaghetti code". Umm.. well it would be easy to build MVC framework on to of plain old ASP, but you got the point.

    That's all what ASP.NET MVC is... but that's what makes it GREAT! Learning ASP.NET MVC will be much easier than learning ASP.NET Web Forms. And you can start learning MVC basics today. Just google MVC framework and read/play with it (RoR, Django, Symfony...). They are so much alike.

  • "those that can't wait to get their hands on the MVC framework and see this release as long over due"

    I'm solidly in this camp, and currently working around all but the bare essentials of the asp.net server side framework in the user controls I'm developing. Its one of those times when it seems like exactly what you're hoping for is being delivered, and I really don't think I'm risking dissapointment because from many of the samples I'm seeing its being used in a very similar manner to what I'm envisioning.

  • @Tom - Trust me, we've been asking for bits through our internal channels and are on the same waiting path as everybody else. I'm sure there will be plenty of time after the first bits drop before the first "official" MVC release (ASP.NET AJAX took just over a year), so hopefully UI components will be able to catch up by then.

    -Todd

  • @bungle- You definitely fall in to the first camp of people I described. :) I understand and partly agree with your points- that ASP.NET MVC is similar to what many other frameworks are currently doing.

    Clearly, if this is where ASP.NET started, there may not need to be a discussion about the merits of WebForms over MVC. But since we all have years and years of experience working with and developing for WebForms now, they're second nature and in some respects much less complicated than unfamiliar MVC concepts (unfamiliar from an ASP/ASP.NET developer's standpoint). Just depends on what you're used to, I suppose.

    -Todd

  • Hi,

    I am not to clear about Code behind and Code beside support in MVC. Can some one make it clear to me.

    After learning ROR in short, i think code behind support will be good to avoid spaagheti code.

    Thanks

  • @IronRuby- ASP.NET MVC will continue to support the popular code behind approach common in ASP.NET pages today. But unlike today's pages, the code behind in an MVC View Page will be -very- basic, only performing the necessary tasks to format and output HTML. All data access tasks, processing logic, etc. should be handled in the Controller classes.

    In that case, it will likely be much more common to see some spaghetti code in MVC apps, but certainly not required. In theory, you should be able to do all of your HTML processing in methods in your code behind and render the results to ServerControls on your page.

    It is clear from ScottGu's post that the MVC View Pages will also have some events (such as Page_Load), but I'm not sure at this point the full scope of events that will be fired by a View Page. We'll have to wait for the preview bits to see that.

    Hope that helps clear things up.

    -Todd

  • Thanks Todd,

    Sorry for troubling you again.

    How close do you think asp.net MVC is when compared to ROR ( Ruby On Rails )

    If i spend more time on ROR currently, will it help me in asp.net MVC in future....?

    Do you compare SubSonic closer to Asp.Net MVC or ROR closer to Asp.Net MVC.

    Sorry, but there are many unclear things looping in my mind.

  • Hi Todd,

    Some are probably just frustrated that MVC existed long before ASP.NET came along. We were building our Java web apps using MVC in the late 90s.

    I definately think ASP.NET MVC will bring over that percentage of the community that think MVC is the only way to work - so bring new developers to ASP.NET

    Probably the biggest problem with the current WebForms model is that it is designed for synchronous operations in that ViewState needs to be kept consistent. This poses problems with AJAX apps because the browser can issue multiple concurrent requests to the server.

    David

  • There is a lot of hype around MVC. I am excited about this release although I doubt our company will be very quick to adopt as we have a lot of C# WinForms programmers who cherish the current WebForms model because it is familiar.

  • I cant wait until it comes out. see what they have stealthly added to the framework that we are not aware yet.

  • If I could just chime back in for a second I would like to back up “Site Smart” ‘s point which is that Microsoft developed the Webforms model to allow Windows developers to transition to the web easily and it has been enormously successful in that respect.

    I think when people say “Microsoft should have come out with an MVC framework from the start” they don’t realize how many developers didn’t have the first clue about web development back then and how they would have never moved to the web if not for the webforms model. Even many developers who didn’t start out on Windows find it much easier to grasp web programming when things like viewstate are taken care of for them.

    I’ll be the first to criticize Microsoft when they do wrong but Webforms wasn’t (and really still isn’t) a case of that happening. They actually did a tremendous service to their customers by doing it that way and I for one think they should be commended.

  • @Tom- I support that opinion completely. And so do Microsoft's research numbers which show how ASP.NET has thoroughly beat the other platforms in the market by becoming the leading web development framework (not my opinion, result of 3rd party surveying).

    I fully expect to continue developing with WebForms well in to the future, but I'm happy to have a new ASP.NET based tool at my disposal for projects that need it.

    -Todd

Comments have been disabled for this content.