Some time ago, I decided to base my next project on FubuMVC. Since all the posts I found on the Web are a bit outdated (and required a lot of steps that might scare you away), I decided to write a fresh one. So, here are a few steps required to display a catchy phrase some of you would recognize.
Update: Since the post is becoming too big, I'm moving the "catchy phrase" part to the next one.
Prerequisites
- Create an empty Web Application project.
- Open the "Add Library Package Reference.." dialog and add
FubuMVC.FastPack (which adds the necessary Fubu bits as well as NHibernate, StructureMap, HtmlTags, and a bunch of other stuff I'm not familiar with yet).
For those of you scared by the numerous steps required to setup a typical Open Source project, this would be a pleasant surprise.
While many frameworks have their conventions, good or bad, they are usually hidden deep inside, and take some effort to override. For example, one of the most infuriating conventions in ASP.NET MVC for me is having to place your View into the Views/{Controller} folder. Not only did I have to read some ScottGu stuff to discover it, it's pretty hard to change. The problem is that this convention is a part of the view engine, rather than a separate class.
Fubu is done differently. Take a look at the ConfigureFubuMVC class that comes with the package:
public class ConfigureFubuMVC : FubuRegistry
{
public ConfigureFubuMVC()
{
IncludeDiagnostics(true);
Actions.IncludeClassesSuffixedWithController();
Views.TryToAttachWithDefaultConventions();
Routes.IgnoreControllerNamespaceEntirely();
}
}
There are conventions as well, so that you don't have to start from scratch, but rather than bury them deep inside, the team made them visible. And editable, too -- it's pretty easy to change. My only complaint is about the "TryToAttachWithDefaultConventions" thingy -- I'd rather make it explicit, so that a newbie like me won't have to investigate what the default conventions are (more on that below).
So, What Do We Have There?
First, we see that all classes that end with "Controller" should be treated as, well, controllers. However, I'm not sure that they are as controllery as you might expect from classes suffixed with "Controller". Meaning that they don't control much. These classes are just POCOs, they don't inherit from some required base class, nor should they implement a particular interface. They are just classes that provide action methods. So, we need a convention in order to distinguish them from other classes. The convention is the same as in ASP.NET MVC, but it's easily substituted with another built-in, or custom, convention -- you don't have to rewrite the ControllerFactory for that purpose. For example, I could easily substitute it for:
Actions.IncludeTypesImplementing<IController>();
Next, we see that the Views should be attached with default conventions. As I mentioned before, I'd rather see the explicit convention here. While having a shortcut is cool, in order to use a convention, I need to understand what it is. Also, "Default" means different things for different devs. Anyway, this is what they really wanted to put there:
Views.TryToAttach(x =>
{
x.by_ViewModel_and_Namespace_and_MethodName();
x.by_ViewModel_and_Namespace();
x.by_ViewModel();
});
What do we have here? Back to our action methods, they don't really decide which View, if any, to render. They just convert your input to output. I admit this is very convenient, since I'm using a single view per action method in, like, 99% cases. However, I don't know yet if it is possible to render different views from a single action -- any hint is appreciated.
Back to our convention, we first try to find a View using the ViewModel, namespace, and method name, then by ViewModel and namespace only, then... you got the idea. "ViewModel" means that the system looks for the strongly typed views that have model types matching output types of the action method to match. "Namespace" means that we are looking for a view in the same folder as our "controller" (which is much more convenient than keeping all views in a separate directory tree, by the way). Finally, "MethodName" means that the action method should match the view name, similar to ASP.NET MVC. Note that these are WebForm view conventions.
The last line:
Routes.IgnoreControllerNamespaceEntirely();
should probably have been the first one, since this is what we do first: routing. Anyway, what we have here is we tell Fubu not to include the controller namespace in the URL. You can also ignore controller names (the URL is defined by method names entirely, substituting underscores with slashes), ignore class or method suffix, and apply all kinds of other global conventions, as well as some fine tuning for individual routes. One thing that Fubu does out of the box and which is not written here specifically is ignoring the "Controller" suffix, just like ASP.NET MVC. Again, I'd rather see it here in the default configuration class, than hardcoded deep inside somewhere, with no obvious way of detecting or changing. Having some of the default conventions open for modification and others hardcoded is a bit confusing and requires some esoteric knowledge. Fortunately, after taking a deep breath, I managed to calm myself and realized that this is not the end of the world, since nobody's going to want "Controller" suffixes in their URLs anyway.
This Post is Becoming Too Boring
This is what happens when you write it several days on and off. Time to wrap it up. FubuMVC is not weird geeky stuff. It's actually simpler than ASP.NET MVC. I haven't tried advanced stuff yet, but judging from what I hear, the advanced stuff is also simpler.
What's even more important, Fubu is pure fun to work with!
While I'm taking a break before writing a new post, you can check the Fubu guides, and download the examples from https://github.com/DarthFubuMVC/fubumvc-examples.git. Next time, let's see some real sh*t in our browser!
