Areas

ASP.NET MVC 2

Jeffrey Richardson — Mon, 17 Aug 2009 17:03:14 GMT

ASP.NET MVC 2 has been announced with the release of ASP.NET MVC 2 Preview 1. After having read through the rather lengthy overview of new features written by Scott Guthrie. Many new great features have been listed, but the two that tend to stand out the most is support for areas by project and template helpers for editing and displaying data.

Project based areas seemed to be an official solution to my categories dilemma. On further inspection, it becomes apparent that the projects are not logical containers to an area. The areas implementation is still the original namespace based one, with the projects allowing simple tooling support to keep a consistent namespaces in a defined area, as well as some behind the scene build tasks that allow all content to be merged together. However, it does appear though that this has lead to some internal support of areas in general, making my category implementation integration more seamless.

Template helpers appear to be very useful. I already have a few ideas for including designer (quick preview) support for these, utilizing a control designed to provide similar functionality to the Editor/EditorFor and Display/DisplayFor. These methods return a string, and are used similar to how other HtmlHelper methods are used, such that it could be assumed that the return value would be the markup to send to the client. Looking into the code, however, shows that these methods return an empty string, while using the ResponseContext to write the markup directly to the response stream. I believe it’s safe to assume that this was probably a quick port to show off the functionality, and later will return the markup rather than write it.

One bit of annoyance with regard to extending ASP.NET MVC is that the most useful classes tend to be set internal, such as InputHelper and TemplateHelper. This makes it difficult to integrate at certain levels, especially in cases where the extensions have already done the work the public interface does or doesn’t need to do the work. This creates a larger problem in the case the public interface is much more limiting than what the extension is trying to offer. This situation tends to leave three less than ideal solutions: building the extension directly into the assembly, which requires the entire assembly distributed as standalone, not allowing integration with other some other extensions, including the relevant source directly in the extension, which causes updating to be more difficult, as well as ensuring internal dependencies, or creating a wrapper which reflects the code, which requires much higher privileges, and can’t run medium trust as a result.

There are a few new features that leave more to be desired. However, this release, as well as the future planned releases appear to be a great step forward in this technology, to which I look forward to more information.

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.