Recently I have been using the ASP.NET MVC framework for a project at work. And one of the requirements was that certain data inputed in to the URL be tightly verified. I originally thought that data was verified by the type specified in the ControllerAction, however I came to find out that it wasn’t. So if you have say a page number and the user enters a letter in the URL the application just proceeds on it’s marry way. For example on the Kigg site:

1. http://kigg.dotnetslackers.com/Story.mvc/Category/Lifestyle/1
2. http://kigg.dotnetslackers.com/Story.mvc/Category/Lifestyle/a
3. http://kigg.dotnetslackers.com/Story.mvc/Category/Lifestyle/
4. http://kigg.dotnetslackers.com/Default.aspx

I am not sure yet if this is because Kigg is implemented with a int? and any failure of the parsing results in a null. But that wouldn’t explain the 3rd result in which Kigg returns the category as if it was the 4th result. I would expect that the 3rd result should return the same results as the 1st result. This setup can results in many SEO issues where I can inject keywords in to the URL with malicious intent and still have it resolve correctly. For example:

1. http://kigg.dotnetslackers.com/Story.mvc/Category/Lifestyle/coderjournal

So my recommendation to my readers is to also implement a URL Rewriter to force normalization on to the MVC URLs. I am personally using my own URL Rewriter on this project that I am creating to better control my inputs, by providing type validation, into my application. At the very least use the built in verification and don’t put null in the defaults.

RouteTable.Routes.Add(new Route {
	Url = "[controller]/[action]/[page]",
	Defaults = new { controller = "Home", action = "Index", page = 1 },
	RouteHandler = typeof(MvcRouteHandler),
	Validation = new { method = "GET", page = "[0-9]+" }
});

The Validation property that you see on the last line above allows the type of HTTP Method allowed POST or GET usually. And the other properties are similar to what you do with the Default only they are RegEx statements that validate the specific part of the URL.

Really what I would like to see from ScottGu and the rest from the MVC framework is a more extensible Route object or RouteTable. I was really surprised that I wasn’t able to overload the handling of the URL in the MVC framework. Don’t get me wrong the team has done a great job hitting 95% of the potential needs of the development community. However if you fall in that 5% you are either out of luck, or forced to create a new Module, Controller, RouteTable, Route, and a whole host of supporting objects. For instance if I wanted to give the users of my URL Rewriter and Reverse Proxy a common interface that they can both do their advanced URL Rewriting and Reverse Proxying and their MVC Action/Controller setup. I wouldn’t be able to do it unless I basically reimplemented the URL handling of the MVC framework. I might end up doing that in the future, but I will probably wait until the Gold Version of MVC is released. If this was a perfect world I would probably implement some syntax in my URL Rewriter Rules file that looked like:

# if not feed burner requesting
RewriteCond %{HTTP_USER_AGENT} !^FeedBurner.*$
# rearrange old structure
RewriteRule ^/<?'controller'([a-z]+)>/index.html$  /$1/List/page$2.html [C]
# in to new MVC model
RewriteRule ^/<?'controller'([a-z]+)>/<?'action'([a-z]+)>/page<?'page'([0-9]+)>.html$  {controller="Home",action="List",page=1} [MVC,NC,L]

But that is just me making a wish for the future of MVC extensibility. All that I would need to accomplish this task is a little more flexibility in the URL handling. If anybody from the MVC wants to talk to me more about my requirements please feel free to contact me.

Really the last thing, I imagine, that the MVC team would want to cause is more SEO problems than are already created by uneducated developers.

I am really blown back about how fast and easy MVC is to develop with.  I know the guys at Microsoft do a good job with their .NET coding, but I am really impressed by the forethought they put in to MVC.  It builds on top of the standard ASP.NET package, but does it in such a way that makes it lean on top of the already feature-rich (read bloated) ASP.NET Page object.  It really doesn’t feel like I have all that baggage anymore.

These are the following links that got me started designing my very first MVC application.

• Scott Hanselman’s Screencast on MVC
• Quick Start
• Microsoft ASP.NET 3.5 Extensions
• MVC Toolkit

Keep a watch on my blog about for my posts about Unit Testing MVC and using Validators in the Routing table.  Also I am currently exploring if it is possible for my URL Rewriter and Reverse Proxy to be used in combination with the MVC Routing table.  I will keep you informed.

Recently I have been working very hard on getting a new Web 2.0 initiative off the ground. With most new initiatives I like to start out by looking for software development patterns that will help me standardize my structure as well as make the programming experience common for any new members that are brought on the team. However I recently ran in to a structural “pattern” that seems like it is pretty simple and it addresses a common problem in software development. I researched as much as possible on all the common pattern websites that I visit and even went as far as posting on ASP.NET Forums to see if anybody could help me, give it a name. If this “pattern” hasn’t been named yet I am going to be shocked.

I like to consider myself pretty educated when it comes to some of the recent developments in structured software development. However I am at a total loss here so I am presenting this pattern to my readers to see if they have seen it before? For now I am calling this “The Modeling Pattern”:

The pattern I had in mind is to have the same object with different interfaces each modeling the required data for a specific type of User Interface.

In many websites you normally have the same information represented in various different ways. I originally arrived at this pattern after listening to Scott Hanselman’s MVC Screencast. The idea of a model, as in the M in the Model View Controller (MVC), really intrigued me. The more I thought about standard web page designs and how they are mostly based around only one “object”, the more it convinced me I was using the right model. For example you have these two different views of a article on the .NET Kicks site. (Which is a great site by the way.)

.NET Kicks Article Card

I call this a card just for the fact that it is a small representation of all the information for this article, much like a business card is a small representation of all the information about a person.

.NET Kicks Article

Notice how most of the information is similar between the two images above. We know they are similar because it is the same information represented from the database in different views. However the main difference is the amount of information show. Obviously it would be a massive overkill to load the users who kicked the story, and comments, when all that is required is the card view for the front page. I imagine most of this is not new to many of my readers, because SQL lets you create your datasets (models) however you want at will, the real trick in software development is creating the finite number of objects for the infinite number of datasets that SQL can return. That is what I am trying to address with “The Modeling Pattern”, creating a finite number of objects that makes sense based on the views I need for my application, because you obviously don’t want to dirty load all the properties for performance reasons. This is how I would code the above in “The Modeling Pattern”.

interface IUserModel
{
	int Id { get; set; }
	string UserName { get; set; }
	DateTime JoinedOn { get; set; }
}

interface IArticleCardModel
{
	int Id { get; set; }
	string Name { get; set; }
	string Description { get; set; }
	int KickCount ( get; set; }
	int CommentCount ( get; set; }
	void Kick (IUserModel user);
}

interface IArticleModel : IArticleCard
{
	List<string> Comments { get; }
	List<IUserModel> UserKicks { get; }
}

Then with these interfaces you create the objects.

class User : IUserModel
{
	// implement interfaces plus supporting code
}

class Article : IArticleModel, IArticleCardModel
{
	// implement interfaces plus supporting code
}

Then you create a helper class to fill these methods in the data layer.

static class DataHelper
{
	public static IArticleCardModel GetArticle (int id)
	{
		IArticleCardModel a = new Article();
		// get data from database and only fill in IArticleCardModel interfaces
	}

	public static IArticleModel GetArticle (int id)
	{
		IArticleModel a = new Article();
		// get data from database and fill in IArticleModel interfaces
		// including supporting tables such as the collections
		// or fill in some and dirty fill the others
	}

	// do the same for User
}

To use this pattern in something like the MVC framework, you would just use the interfaces instead of the actual object. What this does for you is two fold. Defines the UI model that is required and because it is an interface it doesn’t allow you access to the other properties of the class that maybe null.

So if anybody has seen this pattern before I would love to here about it. Also if you have a better name for it and you haven’t heard of it, I would love it to have something more than the tactical “The Modeling Pattern”.