For those of you that follow me on twitter, you’ve noticed that I’ve been tweeting a lot about a new side project called MVC Turbine.
MVC Turbine is a simple way to provide flow and plumbing within ASP.NET MVC applications, or as its tag line suggest, it converts flow into useful work. A few weeks ago, I had a quick poll on twitter that asked:
As you can see, from the results, 50% of the responses where “Yes, always!” which means that you’re wanting more out of your MVC application.
Please, don’t get this the wrong way: I’m not saying that Phil and the ASP.NET MVC team did a bad job or missed something on the tooling/framework. They did an excellent job on providing an extensible framework that allows projects like Turbine, MVC Contrib, et. al to function.
Why did you build it?
Honestly, I built MVC Turbine for myself a while back so it can help speed up my development of MVC applications. I have made it publically available since I know many developers out there are facing the same issues as I’ve faced during development. Hopefully this work can benefit someone out there.
The concerns that Turbine addresses are the same across all MVC applications: the wiring up of an IoC container within the application lifecycle. In my many adventures with MVC, I’ve realized that the addition of an IoC container to the application made the development a lot faster since it made me focus on the what of the application, rather than the how.
Now you might be saying “Well, my application doesn’t need an IoC to run.” Though that might be true for very simplistic applications, having one out of box doesn’t impede your development or affect the performance of your application. However, taking the time to integrate a container after the fact and ensure that everything still works (by manual or automated testing) seems like an exercise on futility and lack of design foresight.
What does my app gain by using it?
The full documentation of Turbine is out on the Codeplex site. The main feature of Turbine is having an IoC container exposed via a Service Locator pattern. Once a container is in place, it enables the following features:
- Custom Controller Factory
- All controllers can now be resolved through the Service Locator and dispatched out to the MVC framework via the factory.
- Auto and Manual Registration of Components
- Components within the application, such as controllers, routes, modules, services, etc. can be registered automatically at startup or manually during the different integration points that MVC provides.
- Inferred MVC
- By inferring different pieces of your application, such as empty controller actions, removes ceremony from your application decreases the amount of code you need maintain within your application.
Please note that there are other pieces that we can be added into Turbine, such as resolution of IActionFilter through the container. But these and other features will be added at later releases and hopefully reflect any feedback users may have.
Where do I get the goods?
If MVC Turbine sounds something like you want to use or check out, go check out the RTM release. Also, if you have time please provide some feedback in the discussion section. I’m always looking for ways to make the product better.
The RTM release is composed of the following pieces:
Happy Coding!