Azure, MVC, MVC 3, MVC4, Technical

Redirecting legacy pages in

Picture this situation.

An old (legacy) application has landed on your project pile. It is largely built in php, and you intend on re-writing it in MVC.

You will therefore need to somehow inform any parties that may be trying to access the old urls ending in .php, that the resource they are looking for has moved permanently. You may also wish to do this for SEO reasons.

This is something that cannot be achieved easily through routing; by default, IIS will not pass requests for resources ending in .php to your application. Your routing will therefore never be put to use for resources ending with .php.

The nicest solution I found to this issue is to setup a list of redirects within the system.Webserver section of your web.config file. The following listing below will send a HTTP Response status of 301 (Moved Permanently) for any requests for index.php and for prices.php:

 <httpRedirect enabled ="true" httpResponseStatus="Permanent" exactDestination="true">
 <add wildcard="/prices.php" destination="/prices"/>
 <add wildcard="/index.php" destination="/"/>

Index.php will now redirect to /, and prices.php will now redirect to /prices.

This code is currently running in the wild on Azure.

If you are unsure if you need a Permanent redirect or not, have a read of this article from Google.


Put your controllers on a diet

Have a read of this fantastic post by Yngve Bakken Nilsen on cleaning up your controllers.

Nilsen accurately points out that in the real world, controllers, even with the best of engineering intentions, can get bloated. Nilsen focuses on the scenario of your controllers containing Actions for Views and Ajax requests that will return Json data, which is a common cause of controller bloat.

The post demonstrates that you can use SignalR to isolate any Ajax calls away from your controllers. I like his approach, but its also worth noting that you can use the Asp.Net Web API to achieve similar functionality. Using the Asp.Net Web API will allow you to easily separate your controllers that return data from your controllers that return views, but it does leave the client side requesting and manipulation of the data up to you.

Great post all the same, have a read.