For the life of me, I seem to have Journey stuck in my head when I was thinking about writing this post, and as such the title reflects that! Anyway, onto the post...
When developing ASP.NET MVC applications, most examples or sites have shown you starting from complete scratch. This is all and well if you have the time to completely re-write an existing application for 6+ months or have started a v1 product. Right, in the "real-world" the former rarely happens and if your a developer wanting to stay on the bleeding edge, introducing a new architecture into an existing ASP.NET application is fairly tedious. From converting existing pages, supporting legacy routes, and possibly the lack of allowing multiple forms all prove to be a challenge.
Layout
As you know, I'm currently working on the CodePlex team and my biggest task I'm working on is slowly converting the site to use ASP.NET MVC. If you've been to this site, you know how extensive the site is, and how this challenge is very daunting. The one saving grace is that we can do it gradually since we release so often. But, because of this we have to take small steps converting pages (views!) that we can - while maintaining our original master page and other postback functionality. For this post, I'll use CodePlex as a reference point.
We have 2 major sections that we're to worry about while working with ASP.NET MVC. Most importantly, we still have a single form on the page! This is a critical piece of information, because this limitation required us to make decisions we did to get around ASP.NET MVC within a Web Forms world. When working on a MVC view, we render everything within a main content section, and do not use ASP.NET server controls at all. The site also contains a project search on each page but this, however, still relies upon that singe form and the normal Postback model.
Views
Like any web application, you have content pages and you have forms based pages. CodePlex is no different. When converting each of these types, obviously, the former of the two is the easiest to convert. Why? Well, you don't have to worry about that single form tag and there's no need of posting data back to the server. So, when working with true content pages - converting them is as simple as creating your controller, action, and view. Now, just because you're still in a Web Forms model, still does not give you the right to continue to use ASP.NET server controls!
The most challenging portion is working with forms based pages. If you were building a new ASP.NET MVC application from the ground-up, you wouldn't have to think twice about this problem. The reason is that when you create your forms based pages, each logical form has it's own form! Astounding, isn't it. Yes, we've been living in that world of ASP.NET Web Forms world wherein you can have 1 and only 1 form tag (with a runat="server"). Since the application still has this single form tag in place, and we still need to respond to master page events (like project searches) we have to be very mindful of how its done. The biggest challenge is that, if you know the ASP.NET MVC lifecycle, it goes
- HTTP Request arrives
- Routing HTTP Handler executes, matching based on routes
- MVC Route Handler executes controller & action
- The ViewPage is rendered (assuming your calling RenderView)
- The ASP.NET page life cycle is invoked (assuming your using the default view engine)
Do you see the problem? No? Okay, well its the fact that upon a HTTP Post, your Action method is invoked prior to any event occurring within the ASP.NET lifecycle. That means, at an Action method level - you have absolutely no idea if your MVC form was submitted or was it that pesky Project search. Well, this isn't entirely true because how to get around this is by having a hidden input field in which you set a value when your MVC based form is submitted. I'll show a little later how this is used, but you can probably figure out how.
1: <input type="hidden" id="mvcFormSubmitted" name="mvcFormSubmitted" value="" />
2: <label for="UserName">User Name:</label><br />
3: <%= Html.TextBox("UserName", ViewData["UserName"]) %><br />
4: <label for="Password">Password:</label><br />
5: <%= Html.Password("Password") %><br />
6: <%= ViewData["ErrorMessage"] %><br />
7: <%= Html.SubmitButton("submitButton", "Login", new { onclick = "mvcFormSubmit(); " }) %>
8:
9: <script type="text/javascript">
10: function mvcFormSubmit() {
11: $get('mvcFormSubmitted').value = 'true';
12: }
13: </script>
Routing
As you can imagine, routing has become a bit of a nightmare. Why? Well, since we still have to abide by the Postback model, our Views always postback to themselves. For example, /site/login will post to /site/login vs. /site/login posting to /site/processLogin. At first glance, you might think "okay, I'll just check to see if the http method is of type POST within my login action." That would work, but the correct method, which supports later migration away from a Web Forms world, is to have two separate actions. To handle this scenario, you simply use constraints on the HttpMethod within your route definition:
1: routes.MapRoute("GET Login", "/site/login",
2: new { controller = "session", action = "login" }
3: new { httpmethod = "GET" });
4:
5: routes.MapRoute("POST Login", "/site/login",
6: new { controller = "session", action = "processLogin" }
7: new { httpmethod = "POST" }
Now, when your clients request /site/login, the login action will execute, and upon a POST to /site/login, the processLogin action will execute. Another scenario you should consider at this time, is that if you are converting a previous page, say "/Users/Login.aspx" you would want all subsequent requests to be routed to /site/login. To handle this, you can utilize my Legacy Routing methodology that would send a 301 http status code pointing the client to the new url.
1: routes.Add("", new LegacyRoute(
2: "Users/Login.aspx",
3: "GET Login",
4: new LegacyRouteHandler());
Controller Actions
Now it's time to put these two things together. Granted, if you were doing true TDD development, you would have started with your controller & actions, but for the purposes of this post I left it at the very end to show how everything comes together. So a few things to remember, is that we are now assured that our login and processLogin action will execute at the correct time. We also have a hidden input field in which we can determine if it was my form submission that caused the postback, or was it some other control on the master page. So, here's how things should look like:
1: public class SessionsController : Controller
2: {
3: public ActionResult Login()
4: {
5: if (TempData["ErrorMessage"] != null)
6: {
7: ViewData["UserName"] = TempData["UserName"];
8: }
9: return RenderView();
10: }
11:
12: public ActionResult ProcessLogin()
13: {
14: if (Request.Form["mvcFormSubmitted"] != "true")
15: return RenderView("Login");
16:
17: string userName = Request.Form["UserName"];
18: string password = Request.Form["Password"];
19: if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(password))
20: {
21: TempData["ErrorMessage"] = "Username and Password not valid.";
22: TempData["UserName"] = userName;
23: return RedirectToAction("Login");
24: }
25:
26: // process login
27: return Redirect("~/home");
28: }
29: }
As example, I've followed the PRG pattern that I've previously mentioned, but there's one thing here that breaks that pattern. It's the RenderView("Login") if my hidden field does not match. Why do we need to break the pattern here? Well remember the lifecycle I previously mentioned. The only way for events to be fired from your master page, is that it too needs to "postback", thus falling back into the postback model. Once you can safely ditch the singe form, that code can be safely removed.
Final Thoughts
As you can tell, having a mixture of ASP.NET WebForms and MVC forms is not a trivial task. There's a lot to consider when tackling this, and if at all possible SPIKE! Yes, spike your master pages so that you can have a Web Forms master page AND a MVC master page. By doing this, you do not have to follow the single form pattern thus negating almost all this post. I would still recommend using the legacy routing to redirect your users to the new page as well as the PRG pattern, but you should always be doing that anyway :) Well, hopefully this post has served its purpose and given you some ideas on how to approach converting existing ASP.NET applications to ASP.NET MVC. If you have any other suggestions or better recommendations, please add a comment!
0bbe247a-0320-4f2b-9280-ecd8972171d7|5|3.0