In ASP.NET MVC, we can display data in partial views either by using Html.Partial/Html.RenderPartial or Html.Action/Html.RenderAction. In this cartoon, Mark clarifies Nancy about the differences between the two and when to use what.

The validation framework of ASP.NET MVC is designed in such a way that it could be easily customizable/extensible at many points. The validation system is built using lot of classes and it's quite difficult to understand all of them. Sadly, there is no much documentation available in MSDN to help out. As default, the validations are performed by decorating models and properties with validation attributes. These validation attributes are available in a separate assembly called System.ComponentModel.DataAnnotations.

Sometimes, in applications we need to apply or perform validations in different ways. For ex. say we want to store the validation rules for a model in database or in xml files. In these cases, we have to go for implementing custom validation solutions and for that understanding the built-in validation model is trivial.

In this article, we are going to see how we can create a custom ModelValidatorProvider that validates models based upon the rules specified in the xml files and works side-by-side with the other built-in validator providers.

In ASP.NET MVC, we can construct html from code using the TagBuilder class. The built-in html helpers uses the TagBuilder class to generate textboxes, checkboxes and other html stuff. Generating html from code is not flexible because every time we need to alter the html we have to go for recompilation.

We all know that, the built-in ValidationSummary html helper displays the validation errors as an unordered list but in some cases we need to customize the way in which the errors are being displayed, say as a table instead of list. The ValidationSummary method creates the list inside the code and we can't customize it. All we could do is create our own custom helper to display the errors as a table.

It would be nice if we could pass the html structure or template that controls the way in which the validation errors are being displayed to the user to the helper from the view and that's what the subject of this post.

Uploading and returning files in an ASP.NET MVC application is very simple. The POSTed file(s) are available as parameters directly in actions through model binding. The files in the server can be easily sent as response to the clients through its rich support of action results.

There are already articles written on this subject. So why another article? Well, in this article I gathered the important concepts that are scattered in different posts, threads in a single place. I'm sure this article will help the MVC programmers to increase their grip on the framework.

As the name, Controller factory is the component responsible for searching and creating controllers. Like many other components, ASP.NET MVC has a built-in factory named DefaultControllerFactory that's pretty sufficient for most of our cases.

Searching a controller is a perform intensive job and the DefaultControllerFactory does some efficient caching mechanism to avoid looking for controllers every time when there is a need. In this article we are going to explore how the DefaultControllerFactory searches for a controller and what kind of strategies it uses to do the process efficiently.

Knowing how the DefaultControllerFactory works will help when we go for creating a custom factory. First we will see the basics then we slowly dive into the inner workings of the factory and its dependencies.

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.

This post is more kind of tip. The action link html helpers really simplifies our job in generating hyperlinks. These html helpers are integrated with the routing infrastructure and that helps to generate links very smartly. There are lot of overloaded versions available but most of them takes the route values as an anonymous object.

Suppose we need to generate an URL like below,

http://mapservices.com/location/show?pos.lat=12.12&pos.lon=23.5

The querystring names contains a "." operator and when you use an anonymous object to pass these values as new { pos.lat = 12.12, pos.lon = 23.5 } you will run into an exception. How we generate urls like them using built-in action-link helpers is the rest of this post.

Cross Site Request Forgery also known as CSRF (XSRF) is a widely exploited website vulnerability. In a CSRF attack, a malicious site instructs a victim's browser to send a request to an honest site, as if request were part of the victim's interaction with the honest site, leveraging the victim's network connectivity and the browser's state, such as cookies, to disrupt the integrity of the victim's session with the honest site. One of the popular technique to prevent CSRF attack is by using security tokens (from here).

ASP.NET MVC suports prevention against CSRF through the AntiForgeryToken html helper and ValidateAntiForgeryToken filter. The AntiForgeryToken is supported only for the POST requests and not for GET and this makes sense because the GET operation has to used only for safe operations (as per HTTP spec.).

In some applications we need all the POST operations should be validated for the anti-forgery token and in those cases instead of decorating all the POST actions in the application with the ValidateAntiForgeryTokenAttribute we can create a custom authorization filter and apply it globally, that's what we are going to see in this article. We will also see how to create a html helper that renders form along with the hidden field that contains security token.

Value Providers are the components that feeds data to model binders. The framework contains a bunch of built-in value providers like FormValueProvider, RouteDataValueProvider, QueryStringValueProvider and HttpFileCollectionValueProvider that fetches data from Request.Form, Request.QueryString, Request.Files and RouteData.Values. These Value Providers are called in the order they are registered and so the one that registered earlier gets the first chance. We can easily restrict the model to bind with data from a particular Value Provider.

The interesting thing is we can even create own custom Value Provider to feed data to models. In this article we see how to create a value provider that feed data from session.

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.