I made a major paradigm shift earlier this year in terms of programming methodologies. See, I’ve been programming own my own (for the most part) since I was 9 years old, but I’ve never paid attention to how other people coded. I got my start writing RPG’s with my childhood friend and went on to write line of business apps for small and eventually large companies. Because of my lack of knowledge of the outside world, I repeated myself constantly, re-invented the wheel countless times, and never dreamed of testing my code beyond what my friend @plip calls “Exception-Driven Development”.
I credit my enlightenment to three things: my newfound co-workers, my own desire to constantly improve, and ASP.NET MVC. The first two are self-explanatory. The last might seem suspect. How can a framework change the way a person thinks about programming web apps?
I started using ASP.NET (from here, known as “Webforms”) a few years ago and really dug in. Because I like to at least feel like I know what I’m doing, I got to know the framework top to bottom. I loved how creating a web app was almost as easy as creating a windows app. I didn’t love how far I was removed from the underlying HTML, CSS and Javascript. Oh, well… Just drag a control on the design surface and shut-up!
Enter the new hotness. MVC zooms me in a few levels of abstraction and reminds me of what is really going on behind the scenes of a web application. If http is the metal, MVC is closer to it. Instead of clicky-draggy controls, I have to use the keyboard A LOT more. As a result, I actually know what’s going on. On top of all that, IT’S EASIER!!
After using MVC for some time, developing apps via BDD, I now feel like I know MVC top to bottom. After getting to know MVC so well and some residual (albeit waining) knowledge of Webforms, I wanted to provide my developer friends entrenched in Webforms-land a way to make the big switch, if they so choose.
Some Reusable Concepts in Webforms and MVC:
Page to view
In Webforms, you have the concept of a “page”. The page contains the big three (HTML, CSS, and JavaScript) and some place holders for data. Very close to the same thing with MVC. In MVC, I have the concept of a “view”. A view contains the big three, and some place holders for data.
Controls to Helpers and JQuery
In Webforms, you have the concept of “controls” that you can drag onto your design surface. The controls will eventually get rendered down to the big three. In MVC, I have the concept of “Html Helpers”. No dragging. Instead, you type the name of the helper into your view. Same as a control, an HTML helper gets rendered down to the big three when the view is loaded. Also, to make your UI elements look and feel snazzy, you’ve got JQuery. Actually we all do. JQuery is just a Javascript framework/library, so it doesn’t care whether you’re using PHP, Rails, or ASP.NET (or even ASP Classic for that matter). Code your own HTML or use a Helper, then apply JQuery to it… Victory.
Code behind to controller
In Webforms, when you want to add logic or data to a page, you drill into its “code-behind” file and add code to the Page_Load method. In MVC, I have the concept of a “controller” that has “actions”, each responsible for combining my data with my views.
Events to routes and methods
In Webforms, when you want a button to do something, you attach an event to it which appears in the page’s code-behind. Any actual logic that happens, does so during the post-back (after the post, before the back) and the page is (typically) redisplayed after the event takes its course. In MVC, I have links that describe the controller and action I want to kick off. If my action needs to receive some data (as is typical in a post-back), then my form action should describe the correct controller and action, and my action needs to know what to receive.
User controls to partial views
In my last year using Webforms, I had gotten into user controls big time. They are a great way to re-use code, which is my favorite pass-time. In Webforms, much like a typical control, a user control is a markup/code-behind combo that encapsulates some reusable, displayable functionality. However, unlike typical controls, user controls are custom and don’t come in a DLL. In MVC, I have something similar in the concept of a “partial view”. A partial view is simply a section of an HTML page with place holders for data. Like views, partial views can be rendered by controller actions. They can also be referenced in views themselves with a single line of code.
Master Pages
Where would we be without master pages, right? Imagine templating an ASP.NET website without a master page! As it turns out, Webforms master pages are so great, that they’re exactly the same in MVC. How’s that for reusable knowledge?
Things you’ll have to change:
Page lifecycle:
In Webforms, you typically think of an aspx page loading and then its code-behind Page_Load method being called. That’s not really what’s going on, but from 30,000 feet, everything looks simpler than it really is. Who knows? Maybe you have memorized the Webforms page lifecycle like I did. Well, throw away your complicated charts and graphs. It all gets a LOT simpler. In MVC, I have a route, a controller, a method, a model, and a view. The user enters or clicks a URL. The URL gets parsed into a route. The route specifies the controller and the method. The method scrapes up a model and returns a view.
Postbacks:
The concept of an http post is intact in MVC. As expected, right? MVC is “closer to the metal” as they say, so your typical http protocol methods are large and in charge. But, in Webforms, you have the concept of a “post-back”. A post back is nothing more than a page posting back into itself. In MVC, you have to put in some extra effort to achieve a real post-back. Instead, you post into actions that may or may not return the same posting view.
Models for Views:
In Webforms, the way to put data on a page is to call into the control on the page and give it the desired data. In MVC, I have to think about things a little differently. You know what a model is. Now imagine a view that expects a model with certain properties that the view may or may not decide to use. In MVC, when a view is rendered, it is often combined with something called a “view model”. At that point, any place holders are replaced with model data and the view is delivered to the browser. The difference is subtle, but it’s important. Instead of telling controls what to do, you provide them with what they need and let them do it on their own.
Viewstate:
In Webforms, state (anything kept in memory) is simulated by flooding the user’s browser with seemingly endless strings of encoded data called “Viewstate”. Every time the form is posted, all that “state” is transmitted and re-populated when the page is rendered again. In MVC, there is no state, just like any other web technology. The only thing that is transmitted is what you specify. This is dramatically cleaner and more efficient. Instead of depending on Viewstate to hang on to label and text box values, you are responsible for populating and repopulating. It turns out it’s not that big of a deal with help from the model binder and view models.
Give it a try!
If you’re an serious Webforms developer, you’ll probably end up loving MVC after you get comfortable with the framework. I hope some of this information is helpful as you take back control and move to ASP.NET MVC.
