A few days ago, I blogged a response to Rob Conery’s question entitled, Why MVC Turbine? Since then, Rob has been so kind to send me an email saying Thanks for the blog post, but…Dude, I still don’t get it. Help me reach the ‘aha!’ moment. As I told Rob, after I re-reading the blog post and the tone it had, I whole heartedly agree with him: The post did not answer his question.
So Rob…
My apologies, mea culpa, lo siento. I really appreciate your feedback and your assistance with developing a valid message for MVC Turbine (Turbine). You’re a great guy that has a trustworthy voice in the .NET OSS ecosystem, so I take everything you say very seriously (Oh yeah, I owe you a beer next time I see you :P ).
So here’s the post to explain the entire context around MVC Turbine. For the shorter (yet anemic version) post, check out the original post.
Note:
If you’re looking for code, stop reading now. There will be no code in this blog post. However, I will be covering some concepts that will affect those who are developing complex applications with ASP.NET MVC.
One thing that Rob mentioned in his email was that Turbine seems to be an IoC for IoC. Although this might seem to be true at first glance, that’s the intended point. This misconception is due to the fact that Turbine provides a facade (abstraction) on top of a community supported IoC container. In all reality, MVC Turbine is not about an abstraction of IoC, it is about composition within an MVC application. The IoC component is just a by-product of creating a way to make ASP.NET MVC support composition within an application.
In particular, the concept that MVC Turbine introduces was developed to aide the development of my old product, Inofile. And some of the other features where inspired by the conversation with the Herding Code guys. This is the reason why Turbine has the concept of a “blade” (or component) at its core; this piece is how the Turbine runtime assembles the application for you and allows you to extend your application by providing cross-cutting concerns with ease, thus allowing the developer to worry about pieces more important to the application in question.
…But What About The IoC?
Again, the IoC piece is just a by-product. While talking with fellow ASP.NET MVPs, Insiders and fellow ASP.NET developers working with MVC, I kept hearing the same idea, I use IoC to help my application do X which allows me to provide Y feature. In their context, their IoC container provided nothing more than basic plumbing for wiring up dependencies for their controllers. In rare cases, the extra effort was made to provide support for other MVC pieces such as Action Filters, Model Binders, etc.
If you’ve taken the time to grok the MVCContrib project, you will see that they already ship an IoCControllerFactory, so the generalization (abstraction of IoC) is not a new thing. If this method seems to you as off the wall concept, you can always one of the container specific controller factory that ships with the MVCContrib bits to suit your application needs.
In essence, we are all hitching our wagons to a star.
Ok…but how is it a by-product??
Most IoC containers in the .NET realm provide a way for you to register common types. For example, one can use any container to register all types that implement IController, IModelBinder, IViewEngine, etc. Taking this concept and the need for Turbine to register its runtime components (IBlade, IRouteRegistration and IServiceRegistration), it made complete sense for the two worlds to meet somehow.
While looking through the options on how to get this accomplished, it became evident that keeping the work Turbine was doing to register/resolve its runtime types within the black box was a little selfish and short-sighted. It occurred to me that providing a way to extend such flexibility into the actual application (via IServiceRegistration) would be beneficial to application builders (such as you and me). At the same time, you as a builder will have to give up some control on what you can (or not) do within the registration and resolution of your components for the application.
As I mentioned in the Injecting your IoC into MVC Turbine post, I originally thought of only supporting Castle Windsor as the IoC for Turbine. The reason why I opted out of this idea was because developers love their tools; in other words, by going through the extra effort (and creating the IoC abstraction layer) to make Turbine work with any IoC, I hoped to broaden the audience for the project.
What can I say, this by-product is nothing more than eye candy for the project. Again, mea culpa for adding this extra layer of indirection in order to benefit the project. :(
Aren’t I just creating a dependency on MVC Turbine?
If you read through previous section, the the question (title for section) might have crossed your mind. So, yes, you are sort of switching the dependency on your IoC container to a dependency on Turbine with your IoC container.
Is this a good or bad thing? Honestly, I’m not sure; that’s for you to decide. I look at it as six in one, half of dozen of the other for the feature trades (IoC + custom wiring vs MVC Turbine + loss of control). Sure you can control how to build all the hook ups to ASP.NET MVC with your IoC du jour, but like many things, it will require some work. Now, I’m not saying that this extra effort is time ill-spent but it is some extra time overall for your application. Now if you leverage all hook ups that Turbine provides out of the box, sure it saves you time but it costs you control for the overall assembly (putting together) of your application.
The interesting thing about this piece of puzzle is that other frameworks are offering something similar to what MVC Turbine tries to address:
At the end with any framework, you’re giving up some control or adding an external dependency for your application in order to outsource some of the extra work to get work the job done. It is up to you, the developer, to figure out if the trade is worth it for your context.
Version 3 of MVC Turbine will outsource its registration and resolution for runtime components to the Managed Extensibility Framework (MEF) since these pieces are extension points for the Turbine runtime. I tip my hat to Glenn Block for taking the time to help me work out how I could easy migrate the current bits to leverage MEF’s features without forcing the consumer (you) to be bound to MEF (another issue that IoC purists have). Stay tuned, more to come on this as I get free time to work on these pieces.
So what now?
Great question! Honestly, I don’t know. I figured this blog post would make a great “tell all” story behind my thoughts around MVC Turbine and how I see it fitting within the ASP.NET MVC world.
All I can say is that if you’re curious about MVC Turbine, try out. If you have any questions, please don’t hesitate to ask a question on the discussion board or email me at javier-at-lozanotek-dot-com. If you think that MVC Turbine is overkill and should go away, then PLEASE, email me your reasons. The more I know about your pain points or concerns, the better I can adjust my contributions to you and the community (whether it be by fixing Turbine or some other means).
For now, happy coding.