Welcome to the first in a series of articles about an example FubuMVC migration project. The idea is to take a pretty common example of an ASP.NET MVC application written in a style that was prevalent in 2009 and 2010. There has been some good thinking around how things can be improved in 2011, but for the most part, developers are still making the same mistakes. This means that we are talking about countless sites already in production today and many of these won’t even have any unit tests.
This is a brief list of things that most of these projects continue to get wrong:
- Zero or very few unit tests;
- No build automation, packaging and deployment mechanisms;
- No Dependency Injection and probably no Inversion of Control (IoC) container;
- Controllers have far too many responsibilities;
- A design that reflects a lack of SOLID principles;
- Cross cutting concerns all thrown in the melting pot together leaving unmaintainable code;
- URLS that are oddly designed due to the awkward link between routes and controllers.
Well nothing if you’re happy with that of course. But you might just be interested in getting these basic tenets right so that you can lower your technical debt, improve your design and put yourself in a position of being able to easily maintain and add to the system over time.
So if you’re that person, then in order to fix those things in the bullets above, you need two things:
- Developers who understand or can learn to understand and employ SOLID principles;
- A framework that gets out of your way and actively helps you whilst you’re implementing those patterns.
That is why it’s fair to say both that FubuMVC is not a beginner’s framework and yet it most certainly is! So how does that work then? You actually need to be a skilled developer to use something this simple. Wow, now that’s a sweeping statement, but let it sink in for a bit, and let me explain:
It turns out that, contrary to popular belief, FubuMVC isn’t actually that difficult to use.
The API for setting up FubuMVC is no more complex than that of ASP.NET MVC. In fact, in many ways it’s more intuitive. It’s just that the concepts it uses as obligatory first class citizens, such as Inversion of Control (IoC) containers and Convention over Configuration along with about 10 other good design patterns baked in are not mainstream enough yet to have become commonly accepted best practice.
Developers simply must have a true grasp of the Single Responsibility Principle (PDF) and Dependency Inversion among others. This is a basic prerequisite - something that unfortunately more frameworks don’t force upon you. If they did, perhaps we’d have far less unmaintainable software out there.
As a result, developers new to these patterns are wrestling firstly with understanding why a given pattern is used at all, and secondly how that pattern is being employed by the framework. Developers who are already comfortable with the former, find it much easier to grok the latter, and for them, FubuMVC is a piece of cake once you’ve nailed the initial understanding of the API.
Why does it even exist?
That is the real question that keeps on coming up. When we already have an “adequate solution” provided by a major vendor, then what is the point in pursuing this space any further? That’s what plenty of people out in the .NET community are asking. The answer is quite simple:
Without the innovators, you can never move towards better and more efficient designs.
You have to take a look at Roger’s bell curve on Diffusion of Innovation to properly understand this:
FubuMVC, along with a few other .NET OSS web framework projects such as OpenRasta, NancyFx, Manos and TinyWeb to name a few are all playing in the 2.5% market share right now - probably much less in reality, but they each have their own take on how to approach building web applications and are all innovators in their own right, pushing the boundaries of statically compiled languages that have pseudo-dynamic capabilities.
The true power behind statically compiled languages has been too successfully masked by those not willing to push it to the limits the way that developers do with dynamic languages. Most developers who use static languages go their entire careers without discovering that power - the true definition of “Proficient” when looking at it in terms of the Dreyfus model of skill acquisition, but just not breaking into the realms of the “Expert”.
Probably the first goal for these frameworks should be to break into the Early Adopters’ section. Those kinds of percentages are awesome for any group of OSS frameworks, even if the remaining percentage of users are following the main vendor. In order to get in to that bracket though, we need to do two things:
- Give a clear and definitive instructions on using the framework;
- Teach developers why writing well crafted code is actually better for them in the long term.
What are the business benefits?
Microsoft is never going to be the one that comes up with those more efficient designs no matter how many people they throw at it. Why? Because they’re not focused enough on it, and because they don’t care enough about it. They have to balance speed and time to market with value for money.
Marketing spend is likely to be far more than development spend because what they care about is selling product and building their business to cater to shareholders. That’s what business’ do, and there’s nothing wrong with that.
Microsoft don’t need the best solution to achieve that, they just need the most popular, and they’ve achieved that already by playing in the Early Majority space since the beginning of 2011. But you can’t achieve that and hope to have the most technically sound solution. The latter takes a level of precision and care that costs too much money when a few shortcuts will get you out the door more quickly.
Saying that “it’s good enough” is disingenuous to the development craft. The entire point of becoming a better developer is to learn from mistakes and improve on that design time and again. Saying that “it’s good enough” is however very pragmatic from a business point of view because when you’re running a business, your only real goal is the get the job done and get it live!
So is technical superiority enough for any smaller framework? Not a chance! There need to be real reasons to move, and a clear and present danger in staying where you are. That part can only be decided by those that are on the project. The technical debt they incur during a two year development life-cycle, for example, might cripple their ability to move the product forward. By then it’s often too late to change direction.
As a business owner, you have a fine balancing act going on here. You need to weigh up things like costs involved with bringing skills in off the street to do the job. A more popular, or well supported framework will be much easier to resource in the beginning of course, but that needs to be carefully weighed against the fact that every time a developer at your company writes a “fat” controller with multiple responsibilities, they’re incurring technical debt. It’s not that controllers have to be fat - it’s that most developers don’t know any better, and the frameworks actively lead them in that direction, given that the way conventions are structured in ASP.NET MVC, does not lend itself to SRP.
So how can FubuMVC help?
There are those developers who are more than comfortable enough using ASP.NET MVC as it comes out of the box, or taking advantage of the extensibility points which meet their needs. But as alluded to above, there is no doubt that the framework has its limitations and can only be bent so far before it starts breaking down. But the goal of the series is not about blindly bashing another framework. The goal is to show how simple it actually can be to write flexible and robust software by using FubuMVC for your web applications. In order to demonstrate this, we’ll be taking an existing ASP.NET MVC application and porting it over to produce significantly:
- higher unit testability footprint - right down to the HTML conventions used in your site;
- less ceremonial code needed only to satisfy the framework;
- more time writing your application business logic;
- more intelligent conventions that drive the plumbing code right out of your day to day code.
There is no doubt that FubuMVC was first and foremost designed to get out of your way and let you get on with the business of delivering business value. The trick is - how do you talk about a framework that spends most of its time in the background? We plan to solve that conundrum in this series...
So in the end you’ll have made your decision for your project already, based on technical merits, political pressure, plain old fashioned pragmatism or any combination of those. When it comes down to it, nothing said here will change any of that, but you may just want to find out what it’s like to build something you’re familiar with, i.e. websites, with something not so familiar - FubuMVC.
Still to come in the series
- The Team Meeting - where the experienced team lead guides us through the thinking that goes into a migration project like this, pointing out pitfalls and benefits along the way;
- The Vertical Slice - where we go through the process of establishing the layers of our application and how they interact and transfer between responsibilities;
- The magic of UI Composition - you think you’ve seen some Container tricks in your time? Hold on to your hats for this one;
- The apprentice ventures forth - where we flesh out the established conventions and we show the thinking that a novice will go through when creating some of their own;
- Button down the hatches - where we cover authentication and authorization aspects;
- HTML Conventions - where we show you just how much control and coverage you actually can get in a web project with ease;
- Inside the belly of the beast - where we talk about performance profiling and built in diagnostics.
If there’s something about building websites you’re finding difficult with FubuMVC or are wondering about, then post a comment here and we’ll get something up to get that covered.
Until next time