One of the important feature of ASP.NET MVC is Routing. The Routing infrastructure helps us to map the incoming requests to controllers and actions. The routing module ships with a separate assembly System.Web.Routing and that helps us to use the routing infrastructure outside ASP.NET MVC applications, like in Webforms.

In this article we are going to see about the important details of routing infrastructure. First we start from basics and slowly move to the advanced concepts and at-last we see how we can simplify creating routes by using our own extension methods. For people who are already familiar with the basic things they can jump to the last section where we discuss about creating cool extension methods and that's fun.

When a user request for a static resource like an image, video etc. that is located in a particular folder the ASP.NET happily serves that resource to the user unless we have set some restrictions. Sometimes we need to protect these folders from delivering these resources to users other than the owner. In simple cases we can prevent this through web.config settings but in complex cases like it would be nice if we could control the accessibility through an action/filter and for that we have to direct those requests through MVC pipeline and there comes the RouteExistingFiles property. By setting this property to true we can say MVC to handle those requests instead of giving that responsibility to IIS.

In this article we will see how we can utilize the RouteExistingFiles property with an authorization filter to prevent users from accessing unauthorized resources.

The Model Binding feature takes away most of the burden from developers by taking the responsibility of model instantiation from the information available in the request. Sometimes we meet cases where we need to trigger the model binding process explicitly inside a controller. MVC provides two methods for rescue: UpdateModel and TryUpdateModel.

Both these methods perform the same operation, that is they update the model from the value providers. The difference between them is the UpdateModel throws exception if the model state is not valid while TryUpdateModel returns a boolean as false. Both these methods are generic and we don't need to explicitly specify the generic parameter.

Both the methods take overloads that accepts an IValueProvider. When you don't pass a particular value provider the controller uses all the available value providers to fill the instantiated model.

There is a peculiar problem with these two methods when we try to bind a model that is instantiated through reflection. In this article we are going to see about the issue and how we can overcome that.

Exception handling is a serious matter in any application, whether it’s web or desktop. Implementing a proper exception handling is important in any application. In most cases once we catch the exception we have to log the exception details to database or text file and show a friendly message to the user.

In ASP.NET applications, error handling is done mostly in two ways: at local level using try-catch blocks and at global level using application events. ASP.NET MVC comes with some built-in support for exception handling through exception filters. The HandleError is the default built-in exception filter. Unfortunately, the HandleError filter not gives a complete answer to the exception handling problem and that makes us to still rely on the Application_Error event.

In this article, we will learn about the HandleError filter and discuss about the different exception handling mechanisms that will fit to an MVC application.

In a web application the domain classes and the validations associated with those classes forms the Model. Validation plays a core part in a Model. In ASP.NET MVC, model validations are done by using Data Annotations. Data Annotations are nothing but special attributes that are applied to a class or properties of a class. In many cases these built-in validation attributes are not sufficient to fulfill our business requirements and in those cases we can go for building our own custom validations.

In this article we will see how to apply basic validations to a model and also we will see how to create custom validations by implementing the ValidationAttribute class or IValidatableObject interface.

ASP.NET MVC 3 is a highly extensible framework that allows us to replace most of the built-in parts in the processing pipeline with custom implementations. As default it comes with two standard view engines: Razor and the Web-Forms view engines. The interesting thing is the framework provides extensions that allow us to register even our own custom view engines.

In some web applications the business model is available as XML and developers prefer to use XSLTs for rendering data as HTML. In those cases instead of using the built-in view engines it would be a nice choice to use a XSLT engine that renders the data as HTML. There are couples of XSLT view engines already available: one at MVCContrib and the other at NuGet. In my current project I need a mini XSLT view engine so instead of using the existing ones I implemented one myself.