That's right, the ASP.beer event during the MVP Summit 2010 has been cancelled.

Why?

Since there are a lot other parties going on at the same time on Tuesday night, I'm going to cancel the ASP.beer get together - http://www.nerddinner.com/1416 - at the Tap House.

My intent with this get together was strictly social and meet and greet and the same can be done at other parties without making people jump through hoops to fit things into their schedule. I see it at the end is about being social and getting to know people in the list on a more personal level regardless of the name of the event or who sponsors it.

The MVC Turbine bits are now compiled against ASP.NET MVC 2 RC2 which runs on .NET 3.5 SP1 and Visual Studio 2008.  You can get the bits by going to the CodePlex site.

Please note that this the same feature release as MVC Turbine v2.0 RTM.  The following is compiled and upgraded to work with .NET3.5 in VS2008:

• VS2008 Templates
• Runtime binaries
• Feature Samples
• Nerd Dinner Sample
• Okonau Sample

Again, as I mentioned before, the main development will take place onVS2010 and MVC2 as I get things setup for v3 sometime first quarter of 2010.

Happy Coding!

The MVC Turbine bits are now compiled against ASP.NET MVC 2 RC which runs on .NET 3.5 SP1 and Visual Studio 2008.  You can get the bits by going to the CodePlex site.

Please note that this the same feature release as MVC Turbine v2.0 RTM.  The following is compiled and upgraded to work with .NET3.5 in VS2008:

• Runtime binaries
• Feature Samples
• Nerd Dinner Sample
• Okonau Sample

Again, as I mentioned before, the main development will take place onVS2010 and MVC2 as I get things setup for v3 sometime first quarter of 2010.

Happy Coding!

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.

You Gotta Keep’Em Separated…

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:

• System.Web.Mvc.Extensibility by Kazi Manzur Rashid
• Web Client Developer Guidance by MS patterns and practices

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.

To Infinity and Beyond…

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.

I would like to thank Rob Conery for posing the question:

As the project’s portal states:

MVC Turbine is a plugin for ASP.NET MVC that has IoC baked in and auto-wires controllers, binders, view engines, http modules, etc. that reside within your application. Thus you worry more about what your application should do, rather than how it should do it.

Let’s see how this plays out for your application…

Plain Old MVC Application

If you create an MVC application by using File –> New, you get the full power of the MVC framework but your application is not yet setup to take full advantage of it.  Say you want to take full advantage the separation of concerns that MVC provides but you’re using poor man’s dependency injection (DI) to work around the dependencies for your controllers:

   1: [HandleError]

   2: public class HomeController : Controller {

   3:     public IMessageService MessageService { get; set; }

   4:  

   5:     public HomeController() : this(new MessageService()) {

   6:     }

   7:  

   8:     public HomeController(IMessageService service) {

   9:         MessageService = service;

  10:     }

  11:  

  12:     public ActionResult Index() {

  13:         ViewData["Message"] = MessageService.GetDefaultMessage();

  14:  

  15:         return View();

  16:     }

  17:  

  18:     public ActionResult About() {

  19:         return View();

  20:     }

  21: }

  22:  

  23: public interface IMessageService {

  24:     string GetDefaultMessage();

  25: }

  26:  

  27: public class MessageService : IMessageService {

  28:     public string GetDefaultMessage() {

  29:         return "Welcome to ASP.NET MVC!";

  30:     }

  31: }

Although there is nothing wrong with using poor man’s DI as you start your application, you’ll quickly realize that a manually wiring up all dependencies across your application can be a rather tedious task. However, if you remove the poor man injection, aka remove the default constructor that provides the implementation, you’ll get the following error:

This error is due to the fact that the DefaultControllerFactory that ships with the MVC framework, doesn’t support the resolution of dependencies for complex controllers. Not saying that it should, just stating the current implementation.

How do we fix this?

Fortunately, the MVC framework allows you to provide your own controller factory that can create controllers with complex needs. A sample implementation can be done like,

   1: // Note: For instructions on enabling IIS6 or IIS7 classic mode, 

   2: // visit http://go.microsoft.com/?LinkId=9394801

   3:  

   4: public class MvcApplication : HttpApplication {

   5:     public static void RegisterRoutes(RouteCollection routes) {

   6:         routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

   7:  

   8:         routes.MapRoute(

   9:             "Default", // Route name

  10:             "{controller}/{action}/{id}", // URL with parameters

  11:             new {controller = "Home", action = "Index", id = ""} // Parameter defaults

  12:             );

  13:     }

  14:  

  15:     protected void Application_Start() {

  16:         // Configure the runtime to use our controller factory.

  17:         var controllerFactory = new CustomControllerFactory();

  18:         ControllerBuilder.Current.SetControllerFactory(controllerFactory);

  19:  

  20:         RegisterRoutes(RouteTable.Routes);

  21:     }

  22: }

  23:  

  24: /// <summary>

  25: /// Our 'custom' controller factory

  26: /// </summary>

  27: public class CustomControllerFactory : DefaultControllerFactory {

  28:     protected override IController GetControllerInstance(Type controllerType) {

  29:         // Very simplistic, wire up the dependency here

  30:         if (controllerType == typeof (HomeController)) {

  31:             return new HomeController(new MessageService());

  32:         }

  33:  

  34:         // For all other controllers, have the default implementation

  35:         return base.GetControllerInstance(controllerType);

  36:     }

  37: }

The implementation, CustomControllerFactory, is pretty simple and not very usable for controllers that are not the HomeController. Also, you need know how the controller factory is wired into the runtime so the framework will know how to use it.  Although it’s not a lot of code, you’ll need to know how the MVC runtime works and interacts with the extensibility points.  Don’t get me wrong, if you’re learning MVC, this is a great way to get your hands deep into the code and really grok things.  If you’re a seasoned MVC developer, you’ve either done this several times, or have componentized this piece and re-use it across your applications.

Why MVC Turbine?

The whole purpose of MVC Turbine is to speed your MVC development by having the plug-in handle all churn of the runtime and allow you to focus on what your application needs to do, rather than how to do it.  Here’s a short list of what MVC Turbine does for you:

• Provides a facade for your IoC container of choice (currently StructureMap, Castle Windsor/MicroKernel, Unity and Ninject).
• Extensibility API to take advantage of the runtime.
• Registers all MVC types (controllers, view engines, etc.) with the container.
• Sets up the MVC extensibility points to use the registered components.
• A lot more features…

Taking the example above and making it run on top of MVC Turbine, the code changes as follows (the controller code remains the same):

   1: public class DefaultMvcApplication : TurbineApplication {

   2:     static DefaultMvcApplication() {

   3:         //Tell MVC Turbine to use Castle Windsor as the default container

   4:         ServiceLocatorManager.SetLocatorProvider(() => new WindsorServiceLocator());

   5:     }

   6: }

   7:  

   8: // Use this marker interface to provide service registrations to MVC Turbine.

   9: public class DomainServiceRegistration : IServiceRegistration {

  10:     public void Register(IServiceLocator locator) {

  11:         // Tell the runtime to use MessageService for any request of IMessageService.

  12:         locator.Register<IMessageService, MessageService>();

  13:     }

  14: }

All the plumbing needed to resolve dependencies is handled by the Turbine runtime by leveraging the underlying container. So if you need to add another dependency to your controller, say IFooService, all you need to do is add the dependency to your controller and then register the type within the IServiceRegistration implementation.

Where to go from here?

If you’re interested on what MVC Turbine can provide to your application besides dependency resolution for your controllers, check out the download page for feature demos and sample applications.  Also, check out these blog posts that go deeper into the MVC Turbine runtime:

• Injecting Your Favorite IoC Into MVC Turbine
• MVC Embedded Views with MVC Turbine
• Multiple View Engines with MVC Turbine
• MVC Application Extensibility with MVC Turbine

Happy coding!