In the first part of the series, we have completed the basic functionalities of the blog. We have completed the functionalities to display the latest blog posts, display posts based on categories, tags or search for interested posts. We also created sidebar widgets to display the categories, tags and latest posts.

In this part, we are going to see how we can create an admin console to manage posts, categories and tags. We need a grid control to display the posts, categories and tags. We can't use the ASP.NET grid control because they works based on ViewState. We are going to use a jquery plugin called jQGrid which provides many functionalities required by a typical grid like pagination, sorting, filtering, column resizing and much more. jQGrid is easy to use and most importantly it has a pretty good documentation.

JustBlog Admin Console

We don't want anyone to access the admin page other than the blog administrator. We must secure the admin page through Forms Authentication. We'll also see how to write unit tests for controller actions using NUnit and Rhino Mocks.

There are different ways we can learn a technology: by reading books, by attending conferences, by doing samples and more. I think one of the best way is by creating something useful out of it. One of the useful thing that could be easily created is a blog. In this multi-part series, we are going to learn ASP.NET MVC step by step by creating a blog from scratch.

JustBlog

To keep things simple we are not going to build the commenting system instead we are going to use Disqus. I encourage you to build the commenting system by yourself and that would be a good exercise for you.

We are going to use ASP.NET MVC 4 to develop the application. I'm not good at Entity Framework and we are going to use Fluent NHibernate/NHibernate combo to build the data-access system. You could use Entity Framework if you like. Finally, we are going to use Ninject for dependency injection because of it's simplicity.

In the first part of the series we are going to build the basic infrastructure of the blog. We are going to create the necessary model classes, data access components, controllers and views. At the end of this part we have a working blog where we can see the latest posts, read a complete post, browse posts based upon a category or tag and even search for interested posts.

In the second part, we are going to build an admin console to manage our posts, tags and categories.

In the final part we are going to integrate Disqus commenting system with our blog. We also see about integrating AddThis, FeedBurner for sharing and subscriptions. Last but not least, we also take necessary measurements for SEO.

ASP.NET MVC is a framework that is used to create web applications in MVC pattern. ASP.NET Web API is relatively new framework that makes it easy to build HTTP services that can reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

In this cartoon Mark and Ted discusses about the differences between ASP.NET MVC and ASP.NET Web API. Mark clears Ted when to use the Web API over MVC.

Routes are part of an application and they are defined through code in the Application_Start event. Routes not changes frequently but whenever they requires a change we need to modify the code. In applications where we need frequent changes in routing configuration, defining routes in code is not a flexible option and a better idea would be to place them in xml files or database.

I've created a simple API named XRouter that helps you to define routes in xml files. XRouter helps you to map, ignore and redirect requests quite easily. It also helps you to manage areas in a flexible way. The main advantage is whenever you change the routes, the routing table is automatically updated and you don't need to restart the application.

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.