Handlers – A useful FubuMVC Convention
These conventions have been pulled into FubuMVC.Core and are no longer in a separate repository.
One of the little known treasures of FubuMVC is its highly extensible route generation mechanism. The default policy is great for most cases. But when it falls short, you get a chance to make use of this fantastic little gem: IUrlPolicy.
So if the default policy (configured through the DSL) is great, where does it fall short? It’s not there’s anything wrong with using the DSL-based configuration for your routes. I just like to approach things a little differently.
Routing by Feature/Story
Let me see if I can get point across nice and strong:
I don’t like separating files that are closely related to each other. Period.
First, I’ll give you an example of how I don’t like to do things:
I’m not sure where this comes from – though my suspicions tell me that they stem from the understanding of separation of concerns as they relate to MVC. The idea here is that you have your controller in one folder, models in another folder, and views in yet another folder. This way you can run around your solution trying to find your files.
That isn’t even the core of the issue, though. Look at the Account directory under Views:
We can assume here that each one of those views has a corresponding GET and an optional POST method in the AccountController. These are related, yes, I’ll give you that. However, let me ask you this:
If the logic of how passwords are reset changes, should you have to change anything for how you login?
Well, that’s debatable. I can see how you may have to change some logic to accommodate those logic changes. However, should be FORCED to if the logic remains the same?
My whole point is: why are these in the same class? And what’s the use of putting them into these arbitrary folders?
As I mentioned, I don’t like separating files. So what do I like? Let’s use the following url as an example:
Now let’s consider a new structure:
Now we’ll walk through the important things here from the above diagram:
- Handlers namespace and HandlersMarker
The HandlersMarker is a static type used to indicate the root of the Handlers namespace.
- get_Year_Month_Title_handler class
This class exists within the Posts namespace. The HandlersUrlPolicy starts by building up routes based on namespacing (stripping away the root namespace as marked by the HandlersMarker). So for the Posts namespace, we start with “posts”.
The name of the handler is very important here and there are two ways to name your handlers: 1) Basic names or 2) Route-constrained names.
For both of these, the following rule is applicable:
Your handlers must start with the HTTP verb they apply to (e.g., GET, POST)