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. ASP.NET MVC 3 provides two approaches to build custom validations: one approach is by implementing the ValidationAttribute abstract class and the other approach is by implementing IValidatableObject interface.

In this article we will see these two approaches and learn which one to use at which situation.

I wrote my first post about achieving dependency injection using Ninject right here, there we have discussed about some basic things and even tried a small sample. In this article we are going to explore little more advanced stuff in Ninject. One of the nice thing about Ninject is there are different extensions available along with the core assemblies to work with different frameworks. Ninject has extension to work with ASP.NET MVC framework as well. Along with the core assemblies we need to add assemblies Ninject.Web.Common and Ninject.Web.Mvc to work with MVC projects. Ninject.Web.Common is a common library for both web-forms and MVC. You can download the Ninject core and extensions from here.

We have two options to use Ninject MVC extensions in projects: one is adding the binaries directly to the projects and the other way is installing from NuGet Package Manager Console (Install-Package Ninject.MVC3). In this post we have used the first approach.

"Ninject is a lightweight dependency injection framework for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glue them back together in a flexible manner. By using Ninject to support your software's architecture, your code will become easier to write, reuse, test, and modify."

In this tutorial we are going to have a first look at using Ninject in .NET for dependency injection.

Filters are behaviors that can be added to different stages in the ASP.NET MVC request processing pipeline. There are four different types of filters: Authorization, Action, Result and Exception. The Action filters are the ones that are called before and after an action is executed.

One of the interesting thing with the action filters is, we can even change the parameters before passed to an action and that’s what we are going to see in this article.

In ASP.NET MVC the Routing Module is the URL routing engine that directs the incoming requests to controller actions. There are cases where we need to impose constraints over the incoming requests that are mapped routes. These constraints are used to avoid from directing invalid requests to the controller actions.

In this article we are going to see how to create a simple custom route constraint and supply it to a mapped route.

In ASP.NET MVC the controller is the component that receives requests from the client, performs some actions and returns results back to the client. The controller typically returns results as data or views. The ASP.NET MVC 4 beta comes with a new type of controller called ApiController that helps to create RESTful applications in an easy and efficient way. So having two types of controllers now experts advise to use the default controller for returning views and the ApiController for returning data. Since the default controller itself capable of delivering both data as well as views I don’t see many benefits by introducing the new ApiController. It would be great if the default controller has been extended to add the RESTful features into the MVC framework.

In most of the MVC applications we have controllers that return both data and views. The problem is that from a single controller action we can’t return both data as well as views. Many times we end up writing two controller actions one to return view and the other to return data in either JSON or XML format (for AJAX calls). Having two controller actions makes more chances of code duplication. It would be really nice if we can return both data as well as view from a single action itself. Doing this stuff is quite difficult in ApiController because it doesn’t have capabilities to return views. So we left with the option of using the default controller to achieve that.

The ASP.NET MVC 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.

A service that is created based upon the architecture of REST is called as REST service. Although REST looks more inclined to web and HTTP its principles can be applied to other distributed communication systems also. One of the real implementation of REST architecture is the World Wide Web (WWW). REST based services are easy to create and can be consumed from a wide variety of devices.

There are many APIs available in different languages to create and consume REST services. The ASP.NET MVC beta 4 comes with a new API called ASP.NET Web API to create and consume REST services. While creating REST services it is important to follow the rules and standards of the protocol (HTTP). Without knowing the principles of REST it is easy to create a service that looks RESTful but they are ultimately an RPC style service or a SOAP-REST hybrid service. In this article we are going to see how to create a simple REST service using the ASP.NET Web API.