Yeah this is old hat, I know.  The Preview 5 release was news about three weeks ago.  There wasn't a need for me to upgrade until today.  Both Derik and Casey did great write-ups on some of the issues in migrating from Preview 4 to Preview 5 (found here and here respectively).  I've been using their posts to assist in the transition.  However, as I was making the move I kept getting the following error:

Could not load file or assembly 'System.Web.Routing, Version=0.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

I was following the advice that both Casey and Derik laid out for upgrading the web.config of all old System.Web.Routing references and yet I was still getting the error.  I could search the whole solution for "0.0.0.0" and not a single result would be found.

Turns out that in my haste I forgot to upgrade the MvcContrib library that we are also using.  It had a reference to System.Web.Routing (0.0.0.0).  So it was a little oversight on my part and after I upgraded to the latest MvcContrib, I was back on my way to upgrading, routing problem solved.

Cheers!

Have you ever been traveling through the "internets" and have been presented with the following?

As web developers we know what this means; a form was posted to the page and now you're trying to refresh that same page.  I'm not sure if there's been any significant usability study on the subject but I would imagine my Grandmother wouldn't know what to do here.  Enter the PRG pattern.

What is the PRG Pattern?

While the PRG pattern isn't knew, there isn't much out there on it for the .NET community.  PRG stands for "Post/Redirect/Get", I'll let Wikipedia explain the rest:

instead of returning an HTML page directly, the POST operation returns a redirection command (using the HTTP 303 response code (sometimes 302) together with the HTTP "Location" response header), instructing the browser to load a different page using an HTTP GET request. The result page can then safely be bookmarked or reloaded without unexpected side effects.

While this could be accomplished in webforms, it would be much more difficult since the postback model hangs on pages posting to themselves to implement button clicks and the like.  The MVC Framework on the other hand makes the implementation of the PRG pattern extremely easy. 

But How?  Can I See an Example?

I'm going to use an Login function as an example.  If the login attempt is successful, the user should be redirected to their account page, otherwise they should be redirected back to the login page.

We first will need two actions, one for displaying the login view and one for processing the login attempt, which I've provided below:

               1:
              ///
<summary>
            

               2:
              ///
Displays the login view (the form to enter credentials)
            

               3:
              ///
</summary>
            

               4:
              public ActionResult
Login()

               5: {

               6:
              return View("Login");

               7: }

               8:  

               9:
              ///
<summary>
            

               10:
              ///
Handles form data from the login view, in other words, the form, which
            

               11:
              ///
is on "login.aspx" has a form tag with it's action set to "ProcessLogin",
            

               12:
              ///
the name of this method.
            

               13:
              ///
</summary>
            

               14:
              public ActionResult
ProcessLogin(string email, string password)

               15: {

               16: IUser
user = userRepository.GetByEmail(email);

               17:  

               18:
              if (user
!= null && authenticator.VerifyAccount(user,
password))

               19: {

               20: authenticator.SignIn(user);

               21:  

               22:
              return RedirectToAction("Index", "Account");

               23: } 

               24:
            

               25:
              //login
failed
            

               26:
              //
add some message here in TempData to tell the user the login failed
            

               27:
              return RedirectToAction("Login");

               28: }

               1:
              <
              form
              name
              ="loginActionForm"
              method
              ="post"
              action
              ="ProcessLogin"
              id
              ="loginActionForm"
              >
            

               2:
              <
              fieldset
              class
              ="login"
              >
            

               3:
              <
              legend
              >Login</legend>

               4:
              <
              label
              for
              ="email"
              >Email</label>

               5:
              <
              input
              type
              ="textbox"
              id
              ="lemail"
              name
              ="email"
              maxlength
              ="100"
              value
              =""
              class
              ="required"
              />
            

               6:
              <
              label
              for
              ="password"
              >Password</label>

               7:
              <
              input
              type
              ="password"
              id
              ="lpassword"
              name
              ="password"
              maxlength
              ="256"
              class
              ="required"
              />
            

               8:
            

               9:
              <
              input
              type
              ="image"
              src
              ="<%=
AppHelper.ImageUrl("
              btn_go.gif")
%>"class="submit"/>

               10:
              <
              div
              class
              ="errorlist"
              ></
              div
              >
            

               11:
              </
              fieldset
              >
            

               12:
              </
              form
              >
            

By implementing the PRG pattern, I get nice clean urls that are bookmarkable.  My users also get a nice site that is traversable and aren't presented with confusing security dialog messages

I'm not a fan of the codebehind and designer files that are generated when you create a new ViewPage.  I like a clean solution and for me that means view files (.aspx) that don't have plusses next to them (see the photo to the right and compare the Home and Login folders).

If you want to use strongly typed view data and you don't want to add the codebehind and designer files for the measly few characters you have to type to make a view strongly typed:

               1:
              public
              partial
              class Index
: ViewPage<LoginData>

               2: {

               3: }

In this particular case I have to add two extra files to source control solely for the purpose of having "<LoginData>"...seems like a waste.

CLR Notation

If you want to do the same thing without the extra overhead of two files, simple use CLR notation

               1: <%@
Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

               2: CodeBehind="Index.aspx.cs"

               3: Inherits="ABCCompany.MVC.Web.Views.Home.Index" %>

becomes

               1: <%@
Page Language="C#"

               2: MasterPageFile="~/Views/Shared/Site.Master"

               3: Inherits="System.Web.Mvc.ViewPage`1[[ABCCompany.MVC.Web.Models.LoginData,
ABCCompany.MVC.Web]]" %>

Not the prettiest code I've ever seen, but it gets the job done without extra (needless) files.

This is the third in an ongoing series of articles about my team's transition to the Asp.NET MVC Framework.  In my last post I blogged a bit about how I haven't quite got comfortable enough with the new MVC framework to feel über productive.  What augments the feeling is the difficulty of finding quality information.  The data is few and far between and only sometimes relevant.

I was struggling yesterday to find information on the ComponentController class.  Things I was finding were from the Preview 2 release but finding something on the Preview 3 release was a bit more challenging.  Things are rapidly changing in the framework and the MVC team is not afraid to refactor, rename , or even remove a class.  For example, with the release last night, ComponentController is no longer a worry of mine because it's now gone, removed completely from the framework. 

The MVC framework has been around for under a year (Nov 2007 I believe).  It is now in it's fourth iteration (Preview four, released last night).  While a number of people have downloaded and are using the framework the amount of data/tutorials/blogs/articles pales in comparison to the same information about web forms.  This makes finding the info you need much much tougher.  It's exciting though and must say I enjoy the challenge.  The change in releases doesn't bother me.  It's a bit of a nuisance but I signed up for this trip.  Also the changes are for the better.  The ComponentController class that was replaced yesterday was not easily testable.  The MVC team removed it in favor of the Controller class, which is testable!  Fundamentally it boils down to the fact that I trust the guys on the MVC team and where they're going with the framework.

That trust doesn't help me day to day in moving my project forward though.  In order to find the data I need I've had to be both resourceful and thorough in my reading.  The trick I've found is following a few bloggers closely and reading all of their posts regarding MVC and all comments made to the posts (that's where I find the real gems, in the comments).

Here is a list of bloggers I'm following, obviously some are well-known, others are not.  If you follow some bloggers who post about the MVC framework that aren't on my list please share!! My list:

• Scott Guthrie
• Phil Haack
• Scott Hanselman
• Rob Conery
• Matt Hinze
• Ben Scheirman
• Matt Hawley

Updated to add new blogs (7/23/2008) ... thanks Ben

• Steve Sanderson
• Stephen Walther

Yesterday I reported that I was learning to walk and while I can't quite say I'm walking yet,  I'm feeling a bit more comfortable.  My velocity increased ever so slightly today and I'm encouraged by that and excited for tomorrow!  And to be quite honest that's a perfectly find place to be.

First, it's been tough wrapping my head around the shift from web forms to MVC.  I would caution anyone making a similar shift or considering it, that despite the recognized short comings of web forms and the postback model that one should approach the change expecting a bit of a rough going in the beginning.  Never underestimate what years of articles, blogs, and webcasts about web forms and working in web forms will do to your perspective.  OnClick...gone.  PreRender...gone.

Does the experience thus far cause me to regret the choice to go MVC route?  Absolutely not.  It was 100% the correct decision.  Despite the difficulties of making the shift, there are points where something clicks and it feels better and more natural.  I'm waiting for that shift and those clicks to be more permanent.  The best analogy I can use to explain it is likening the experience to my one year old son who is learning to walk. To him crawling feels right.  When crawling, he's quicker, self-assured, and can generally get where he wants to go.  When he attempts to walk however, he falls down, he struggles to keep his balance, and generally getting anywhere takes longer.  It's temporary though, we know it and that's why we encourage him to walk and push through the awkwardness. In a few years Lincoln will realize (if not verbally but by the way he chooses to move) how much more natural walking is than crawling, a fact that I'm reminded of every time I get down on all fours with Lincoln.

So what am I doing to push through?  First I'm trying to keep in the project.  With smaller tasks and projects always requiring attention, I'm trying to stay in the project as much as possible.  Secondly, I'm thinking about how I think (Metacognition).  Thinking about MVC, testability, loose coupling and other such principles only aid in the transition.  I'm hoping the next two days this week give way to breakthroughs.  Near the end of the day I had some small wins and started to gain some velocity which leaves me optimistic for tomorrow.

We recently decided that with the effort we're putting into our website and some changes that we're making that now would be as good of time as ever to make the switch to the new Asp.net MVC Framework.  We're no Google, but we're currently receiving around 18,000 unique visitors a day and 300,000 page views and hope to grow that number as we make our site easier to use for our customers.  I hope to rely heavily on Phil, Rob, and Scott for assistance if needed. 

The MVC design appeals to us because the large amount of business logic that has crept it's way into the codebehind.  Despite the best intentions, the current site, which is programmed in asp.net 1.1, has had too much logic to creep into presentational areas while running with webforms.  The biggest drawback to this is reduced testability.  Testability should be important in any project but for us it is paramount. We have business rules that if not adhered to amount to real-world fines:

A few years ago a customer bought some lubricant that is sold in an aerosol can.  Since 9/11 aerosol cans cannot be shipped as cargo on airplanes.  Somehow this order made it though the checks we have for this type of thing in the warehouse and made it onto the UPS truck.  At the UPS facility, a UPS employee heard something emanating from a box that sounded like an aerosol can.  At that point he is required by law to check the contents.  When he opened the box he found the aerosol cans.  Despite knowing us and our reputation, he was required to call the FAA and say something to the effect of, "I found some aerosol cans in a package that was scheduled to be flown."  It didn't matter that this was an accident or "just a few cans", we were still fined.  We were warned that if this were to happen again that we would face a fine somewhere in the low six figures. The FAA doesn't mess around.

As we go forward I plan to document on this blog the highs and lows of our transition.  I'll post questions and problems we're having that I hope you can help with as well as tips and tricks our team has found helpful.  Stay tuned as we make the transition.