Lost In Tangent

In the last post, I introduced the specific roles that the ControllerActionInvoker plays in the ASP.NET MVC execution pipeline, and showed how you would inject a custom invoker into your controller (via a controller factory, or custom controller). In this post, I’m going to further clarify some of the juicy details…

<important_paragraph>

After the ASP.NET Routing engine intercepts a request and hands it off to the appropriate controller, the controller grabs the name of the requested action method and asks its ControllerActionInvoker to execute it. As far as the controller is concerned, it has no idea of the concept of an action filter or an action result. All of that logic is embodied within the ControllerActionInvoker. All the controller cares about is that the invoker executes the action it asked it to.

</important_paragraph>

You may be asking why the above paragraph is so important, and if you are then that sucks because I obviously failed at making the really cool point clear. Many people I’ve spoken with have asked me why the controller doesn’t just execute the action itself, since it “houses” the method and could easily handle that responsibility. Which makes total sense, since we’re talking about some extremely basic reflection to find the method, and then invoke it. But, like was mentioned in the above paragraph, more is involved then just that, and you don’t want the controller having to be concerned with the additional “fluff”.

For the record, as far as the core ASP.NET MVC runtime knows, the controller is actually handling all of the request execution logic. This is made clear by looking at the IController interface, which has a single method: Execute. It’s important to understand that this article is talking about the specific Controller class’s implementation of the IController interface.

When the controller hands the request off to its invoker it is basically saying “I don’t give a crap what you do or how you do it, just find this action, and give the client what they want”. The invoker then looks at its controller with a maniacal grin on his (or hers) face and says “Sure, I’ll take care of it muahahaha!”.

Why this is interesting is because it builds additional abstraction on top of what is called a Front Controller. In Martin Fowler’s definition of a front controller, you have an entity (handler) that watches incoming requests and determines which command can and will serve an individual request. Applying this to our situation, the Handler is ASP.NET Routing, and the Command is IController.

Front Controller (Martin Fowler)

The core ASP.NET MVC runtime is itself a front controller implementation. Once we introduce the Controller class though, with its ControllerActionInvoker counterpart, we now effectively have a two-tiered front controller. The outer Handler is still played by ASP.NET Routing, and IController still plays the Command, but because we’re using the Controller implementation, it in turns spawns it own front controller type pattern. The ControllerActionInvoker effectively becomes a Handler as well, one that routes action requests instead of controller requests. The commands that the invoker routes to are ActionResult instances.

This additional separation of concerns (yes I had to say it), makes it possible to add any additional logic that your heart desires within a custom ControllerActionInvoker without having the muddy the controller waters. The architectural pattern (front controller) remains in tact, but your implementation has the freedom to run wild, which is pretty awesome