I’ve been getting different questions via emails, DMs, IMs, etc. that can be summed up by this question:

Once MVC3 comes out, will I need MVC Turbine anymore to provide Dependency Injection (DI) support to ASP.NET MVC?

There is really no clear answer for this, so all I can say is, it depends :)

For those of you that are not aware, MVC3 has added better support for using Dependency Injection (DI) within different parts of your application. This newly added support applies to:

  • Controllers
  • Filters
  • View Engines
  • etc.

These are the same features that MVC Turbine (Turbine) has offered since we first released V1 almost a year ago. However, in order to provide these and other features, the Turbine codebase has had to handle the plumbing necessary to wire up components in a way to provide first-class DI support. This means that a good chunk of the codebase is just there to ‘hook things up’ within the framework pipeline.  After all, we can’t change the underlying framework so we have to make due with what’s available through the public API.

Since the new extension points that MVC3 exposes provide deeper integration to the framework (pipeline), we can now safely delete all the code that we’ve previously had to write; this is a very good thing. As the old saying goes, we can now stand on the shoulder of giants and focus on providing additional support for MVC applications. :)

The biggest value of add that Turbine gives applications is the "Blade” concept, which is essentially a way to provide an extensibility story to MVC applications. In essence you can build Blades that house cross-cutting support to your applications (i.e. Logging, Persistence Management, ESB Support, etc.) without re-inventing the wheel every time. You write once and use everywhere.

Now that the codebase has shrunk, the team can now focus on providing additional features around Blades as well as (to name a few):

  • Registry Mechanisms ala FubuMVC
    • For example provide registries for filters, model binders, types, etc. in order to lower friction with auto-registration within Turbine.
  • MEF Support
    • Split the work (concerns) of the current underlying container and allow MEF to do the heavy lifting for Turbine-specific components.
  • Reusable Recipes
    • Start a Blade Catalog in which you can now assemble different blades (NHibernate, NServiceBus, log4net, etc.) in order to build applications quicker and repeatable.
  • Better Diagnostics ala FubuMVC
    • Leverage the new hooks and registry concepts to gather and report information about the registered types (controllers, view engines, routes, etc.) to the end user (developer) – to help with trouble shooting scenarios.

Also, with the release of MVC3 it is only natural to increase the version number of Turbine to v3; after all Turbine could not exist without ASP.NET MVC.

I am very excited about the new features and opportunities that MVC3 will bring to ASP.NET stack. To me these features are beyond additions to the framework pipeline but more of an on ramp for creating applications quicker and better on top a great web stack.

Happy Coding!