Links and New Site Technology

Now that the change to Wildermuth.com is complete I’ve gotten questions about broken links and such. I am keeping adoguy.com around and redirecting (permanent) the links so that old links aren’t going to break. I don’t plan on keeping it forever but for several years you can be sure. Its worth keeping them around.

I didn’t just do a quick and dirty port to a new CSS look and feel though. This was a conversion of the old code. I don’t use a blog engine but write my own code, mostly as a test bed for new ideas. What was it this time?  Two thinks significant changed: Entity Framework/LINQ as the data access and the **ASP.NET Routing Framework **instead of .aspx links. Let’s take these one at a time:

The use of the Entity Framework and LINQ was pretty straightforward. I used LLBLGen Pro in my old site to do the data access and it held up great.  I only switched so I could test out the Entity Framework on a production-ish system. Not because of any limitations in the old code. Creating a model with the Entity Framework was a snap. My data is not complicated so I didn’t have any complex scenarios.  The only think I did do was change the collection names from singular to plural. Being able to use LINQ to do my queries, search and paging was just spectacularly useful. I am completely in the LINQ camp now.

The second testbed was the new **ASP.NET Routing Framework **.  What is the **ASP.NET Routing Framework **you say? Many of you have heard of ASP.NET MVC. The ASP.NET Routing Framework is the code that does all the custom routing for MVC.  The ASP.NET Routing Framework is going to be released with .NET 3.5 SP1, not part of MVC so its not expected to change nearly as much as I expect MVC to mature. In that light, I couldn’t port my site to MVC wholly because of the limitations in ViewState and ControlState. I could have worked around these limitations but I wanted to be able to focus on the new pieces and not have to re-write every page of the application (or use client-side libraries).  So I found the middle ground of the ASP.NET Routing Framework.  I am using Phil Haack’d great WebFormRouting class to do much of the heavy work of not only routing to the pages but sending the same sort of context that I could have used with MVC.  Its much better than digging into the Response variables IMHO.  You will note that most of the pages are now tail-less (e.g. http://adoguy.com/rants.aspx is now http://wildermuth.com/rants) though the old tail’d versions still work for backwards compatibility. I was able to simple tail-less versions by using his class (note the 2nd one uses an optional URI part):

 
routes.Map("Search").To("~/Search.aspx");
routes.Map("Rants/{page}").To("~/Rants.aspx");

```csharp

I also set up my Rant URI's like so:


```csharp
 
routes.Map("{year}/{month}/{day}/{topic}.aspx").To("~/ViewRant.aspx");
routes.Map("{year}/{month}/{day}/{topic}").To("~/ViewRant.aspx");

```csharp

There was a challenge I had that I wanted the tail-less URI's but I am hosted on Windows 2003 (which means IIS6). I bit the perf bullet though and mapped all requests through ASP.NET.  This means that all requests are running through ASP.NET which can be slower but I thought it was worth the better URI model. IIS7 can do the tail-less URI's without having to resort to everything being a ASP.NET request.  Here's a good article on setting up IIS6: [http://biasecurities.com/blog/2008/how-to-enable-pretty-urls-with-asp-net-mvc-and-iis6/](http://biasecurities.com/blog/2008/how-to-enable-pretty-urls-with-asp-net-mvc-and-iis6/).  You can also accomplish it with URL re-writing but if I wanted to do URL re-writing why'd I use the routing framework instead of re-writing them all?

Its been a fun exercise as well as a re-branding effort.  I hope everyone likes the new site!