I’ve been playing with FubuMVC for about a week for a new project I’m working on (more to come on that soon). So far I really like it, but it’s definitely not for everyone. I thought I would start blogging about some of my experiences learning the framework.
There will probably be a few things I’m wrong about or don’t understand because I’m still new to FubuMVC. But I want to capture my thoughts and impressions as somebody just starting out to help others who may be in a similar situation, or are evaluating the framework for their own projects.
Good: Conventions Everywhere
I think this is where FubuMVC really shines. If you can define the conventions for your application up front then FubuMVC is going to save you a lot of time. For example, FubuMVC lets you define an HTTP Method convention which can automatically apply to all of your controller actions. You could define this convention based on method name (e.g. all Create, Update, or Delete methods only accept POST), input model type, or just about anything you want.
Here’s a snippet of code from my current application. It specifies that all controller methods which accept an input model ending with “Command” require the POST HTTP method.
This is a bit like Aspect Oriented Programming in that you can define cross-cutting rules which are defined once and applied everywhere by the framework.
I really love the way routing/URL conventions are defined in FubuMVC. When working in ASP.NET MVC I find myself hard-coding a lot of routes to get them looking how I want. Defining routes in Fubu is quite a bit different from ASP.NET MVC, but I was able to configure my routing very quickly. FubuMVC also has a really nice diagnostics application that lets you see all routes you have defined for the entire application.
I haven’t dug into the HTML conventions yet but on the surface they seem very powerful. For example, you can define a convention where CSS classes are automatically added to lists for even/odd items. This is the kind of thing that should make it easy to apply cross-application UI changes easily.
In practice I think this will be a bit like CSS where as long as you create consistent HTML, style sheet can save you a lot of time in layout and formatting.
Bad: Sooooo many Models!
Okay this one took some getting used to. FubuMVC uses a “One Model In, One Model Out” (OMIOMO) approach for controller actions. That means that each controller action can only accept one model as a parameter, and returns a single model back to the framework. In ASP.NET MVC you might have a controller action that takes one or more simple parameters and returns an ActionResult, but in Fubu you must encapsulate everything into models.
This is the kind of thing that will turn off a lot of potential users. It looks “enterprisey” and feels like overkill at first. I didn’t want to create a ton of view and input models for my controllers so I tried creating generic models that would be used by many actions. For example, I created an EntityRequest model which had a single Id property that I could pass into all of my View, Edit, and Delete controller actions.
This worked at first, but in the long run it made the UI code a lot harder and more complicated. Creating links or form targets in FubuMVC is really easy if you can just give it a model. Honestly I’m not even sure how to construct a link to a controller action method.
In the long run I decided to simply create models for my different types of actions. And although this is quite a bit different from classic ASP.NET MVC, I actually like it better. It lets me de-couple the UI from the back-end. The UI simply says “give me the link to some model” and Fubu gets to figure out what actually handles that model.
Good: Moving away from Controllers
Once I accepted the OMIOMO approach I decided to make another change and do away with my controllers. Instead I will be adopting a Command/Query approach with Handlers on the back end to handle each command or query. I like this because my handlers can be a bit more generic and not tied so much to the UI.
Now even if you don’t want to move away from a Controller model, I think the real power here is that FubuMVC will still work just fine even if you want to adopt a different architecture.
Bad: Limited support for other view engines
Unfortunately the choice of view engines is limited to ASP.NET Web Forms and Spark. That being said, the ASP.NET view engine is pretty close to standard ASP.NET MVC. But I’d really like support for Razor or NHaml. I’m sticking with ASP.NET for now and it’s not that bad.
Bad: Documentation is still sparse
This comes with any open source project to a certain extent. But FubuMVC is pretty lacking in documentation at the moment. The getting started guides will only take you so far. Once you start trying to build your own application you will likely hit the limits of what you can learn from the guides themselves.
Another thing that complicates things is that FubuMVC went through a reboot a while back so there are some blog entries out there that are out of date with the current version. Many of the ideas in those posts are still valid, but syntax is slightly different in many cases.
Ultimately I’ve relied heavily on the FubuMVC source itself to figure out how to do things. For anyone trying to build a non-trivial application with Fubu it’s probably a requirement.
Lastly I thought I would compare FubuMVC to other frameworks/approaches out there. In many ways FubuMVC can feel quite a bit heavier and more “enterprisey” than other frameworks. But I really think it depends on the type of application you are building and what point in the application lifecycle you are at.
When you are just starting out, FubuMVC can feel very heavy getting everything set up. If you are building a small application with little functionality, you are probably better off with WebMatrix or ASP.NET MVC. WebMatrix especially gets you up and running very very fast.
But as your application grows and becomes more complex, FubuMVC should actually start to feel lighter and more flexible than those other frameworks. I’ve had many experiences with ASP.NET MVC where a change in design requires you to touch many different controllers, views, etc. If you are following your conventions these kinds of changes should be much faster and lighter in FubuMVC. At least that’s my impression at this point.
Perhaps a good approach is to start with something super light like WebMatrix and get a fast prototype up and running. Once your application starts to take shape and you can better visualize your conventions it might make sense to jump over to FubuMVC for the final implementation.
So far I am really enjoying FubuMVC even with all of the ups and downs. I’ll keep blogging about my experience building a non-trivial application with Fubu.