Category support in ASP.NET MVC nearly finished

Jeffrey Richardson — Wed, 25 Feb 2009 20:04:34 GMT

I've finished implementing support in ASP.NET MVC for processing requests and rendering views using categories. Only things left now is to add extension methods that simplify the process of using categories, as well as finish implementing discoverability (i.e. SiteMapProvider).

In the future, I wish to also deal with inline page code. I find it rather ugly, as well as having no page designer support. Although I do not use the page designer to design my page, I do tend to use it as a "quick preview," as well I tend to work with others who require page designer support. I've gone through several possible ideas and implementations, but I believe I have settled on a single idea that should work well. I'll have updates later.

I never specifically planned on releasing any software, but I believe some people out there might be interested in some of the software I talk about, so I've included what work I've done with category support thus far.

Another approach to ASP.NET MVC categories

Jeffrey Richardson — Sat, 21 Feb 2009 06:07:22 GMT

Last night I had an idea for a different approach for grouping related controllers into a category that made so much sense, I'm surprised I was able to imagine it. The idea of actions being grouped into a controller parallels a set of methods being grouped into a class. Taking it a step further, grouping a set of controllers into a category would parallel grouping a set of classes into an assembly.

Under this approach, each category would be created as a separate project, referenced back into the main web application. This has a few advantages over using attributes. First, it allows real separation, as opposed to the superficial separation that attributes employ. Second, it's much easier to cache the controllers into categories, as attribute lookups are no longer required, nor is it required to check that category has been added to the cache (as it can be added the moment the assembly is loaded). It also enforces a design pattern that is much less fragile than attributes (which itself is much less fragile than current implementations I've found), and doesn't feel too restrictive.

I plan on keeping both implementations in my framework, as I see they both have advantages over the other. With many different features being added to my framework, I believe it will be necessary to split it into separate modules. This will simplify adding needed features, without having to include everything.

Category support in ASP.NET MVC? Part 2

Jeffrey Richardson — Mon, 09 Feb 2009 20:04:25 GMT

In order to support categories of controllers in ASP.NET MVC, one must create a new controller factory. The IControllerFactory interface defines two methods to implement, CreateController, which passes in the controller name pulled from the route data, as well as the RouteContext itself, and ReleaseController, which occurs at the end of the request, allowing the controller to be freed. One limitation of CreateController method is that it only gives the controller name, but not the category name. This isn't much of an issue, it's possible to obtain the category name by calling the GetRequiredString method from RequestContext.RouteData object (this is the same method used to obtain the controller and action name as well). The question now, how does one obtain a reference to the correct Controller type? A quick assumption as to how it is done without categories would be to reflect until the correct controller is found, then returning that. Based on this assumption, one would assuming finding a matching Controller, then checking the attributes to determine that the corresponding attribute is set.

However, that's not how the default controller factory works, and for good reason. It's very poor performance to reflect the entire set of types searching for the correct type. Instead, the default controller factory creates what is known as a 'ControllerTypeCache' where it reflects through every type to find all matching controller types only once (when the application starts) and saves that list. It uses a Dictionary<string, ILookup<string, Type>> to store this list. A Dictionary is a one to one mapping between key and value, whereas a Lookup is a one to many mapping between key and value. For each controller type that is found, it's name is derived, then that name is used to obtain the Lookup from the Dictionary (or create a new one if necessary). Then, the namespace is taken from the controller type, and then used as a key to add the type to the Lookup. So, each controller name is then mapped to one or more namespaces, which is then mapped to one or more types (more than one type with the same namespace and same name can occur if they are defined in separate assemblies).

A modified version of this same procedure can be used to support category lookup as well. In this case, it might be preferable to store in an IDictionary<string, IDictionary<string, Type>>, where each category then maps to one or more controller names, which then map to one type. The list can be easily generated using the following code:

private static IDictionary<string, IDictionary<string, Type>> GetAllControllerTypes() {

    // Go through all assemblies referenced by the application and search for

    // controllers.

    IDictionary<string, IDictionary<string, Type>> controllerTypes = new Dictionary<string, IDictionary<string, Type>>();

    ICollection assemblies = BuildManager.GetReferencedAssemblies();

    foreach (Assembly assembly in assemblies) {

        Type[] typesInAsm;

        try {

            typesInAsm = assembly.GetTypes();

        catch (ReflectionTypeLoadException ex) {

            typesInAsm = ex.Types;

        foreach (var controllerType in typesInAsm.Where(IsControllerType)){

            string category = GetCategoryName(controllerType);

            if (!string.IsNullOrEmpty(category)){

                if (!controllerTypes.ContainsKey(category)) controllerTypes.Add(category, new Dictionary<string, Type>());

                controllerTypes[category].Add(GetControllerName(controllerType), controllerType);

    return controllerTypes;

Types can easily be looked up using the following code: cache[categoryName][controllerName] (obviously, this is just a simple method demonstrating the structure; in order to prevent a NullReferenceException, you would want to use TryGetValue instead).

Category support in ASP.NET MVC?

Jeffrey Richardson — Fri, 06 Feb 2009 19:40:49 GMT

For some time, I have been desiring a method for grouping a set of related Controllers into categories. A search for such a category style scheme showed me that, in the web MVC world, such a concept is known as areas, and I found a few examples of people implementing such features on top of ASP.NET MVC.

http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx

http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/

Both of these are the same implementation, with the former having little flexibility and being very fragile, with the latter adding flexibility at the expense of complexity, while still being as fragile. To add to that, neither solution supports discoverability (something I will get to with a later post).

My implementation will consist of adding the route name 'category' to the list of required route names, just like 'controller' and 'action'. Also, the use of an attribute would declare the category of a controller.

[AttributeUsage(AttributeTargets.Class, AllowMultiple=false, Inherited=false)]

public abstract class CategoryAttribute : Attribute {}

This will allow one to inherit from CategoryAttribute and decorate their controller class with the corresponding CategoryAttribute.

public class MainCategoryAttribute : CategoryAttribute { }

[MainCategory]

public class MainController : Controller {

    public ActionResult Main() {

        return View();

    }

}

By defining the route using "{category}/{controller}/{action}/{id}" (note, in this example, {id} is not necessary), the following URL will activate the MainController.Main() method:

Main/Main/Main/

(I notice the lack of originality with naming the sections, and I apologize; I'm not the best at naming things, especially for example purposes.)

My next article will be more in depth about how this model actually works.

Categories

Category support in ASP.NET MVC nearly finished

Another approach to ASP.NET MVC categories

Category support in ASP.NET MVC? Part 2

Category support in ASP.NET MVC?