MvcSupportFacility

Buying a house and dealing with various horrible sicknesses in a wide variety of family members is a great way to use up all of your spare time. That why I build my MVC applications with MvcSupportFacility.

OK in all seriousness, life has been pretty busy and I have been working on building a zero-friction environment like the one Ayende uses in his Rhino.Commons stuff. I'm sure that his is far better than mine (to be fair his has been in use longer and has been polished by more projects) but I wanted to use a different toolset and so I had to bake my own. Where Ayende uses NHibernate and Monorail, I wanted to try and use LinqToSql and ASP.NET MVC.

I've heard many people complain that LinqToSql isn't ready for the big-time but I'm trying to use it in a way that is completely abstracted away so that I can swap it out if necessary. You'll know you're using Linq but not LinqToSql. More on that next time though.

The Wolfbyte.Core.Mvc library contains an MVC ControllerFactory which uses Castle MicroKernel to create Controllers. The advantage of this is that we get IoC on our controllers. The library also contains a simple interface for registering MVC routes (IRouteRegistrar) and a simple implementation that creates the default MVC route.

In order to make it all easier to use there is a simple Castle Windsor Facility which can be initialised with a list of Controller Assemblies and RouteRegistrars from a configuration file. The facility hooks up the Controller Factory, searches through all of the Controller Assemblies for Controllers (concrete classes which implement IController) and registers them in the container and finally asks each RouteRegistrar to apply itself to the default RouteTable. Here's an example configuration file from a sample I've been working on:

<?

xml version="1.0" encoding="utf-8" ?>
<
configuration>
  <
facilities>
    <
facility id="mvc.support" type="Wolfbyte.Core.Mvc.Facilities.MvcSupportFacility, Wolfbyte.Core.Mvc" include-default-route="false">
      <
controller-assemblies>
        <
assembly>WaterCooler</assembly>
      </
controller-assemblies>
      <
route-registrars>
        <
registrar>WaterCooler.ChatRoutes, WaterCooler</registrar>
      </
route-registrars>
    </
facility>
  </
facilities>
</
configuration>

The option to include-default-route defaults to true and so it only really needs to be specified when it's false. If included, it's always the last route registrar called. All you need to do to use it is to create a Windsor Container and initialise it with the config file:

        private void InitializeIoC()
{
var Container = new WindsorContainer("windsor.config");
}



This method is being called in my global.asax.cs file. Note that we don't even need to keep a copy of the container (although you might like to) because the ControllerFactory system keeps a reference to it and uses it. Now that we have Inversion of Control going we can do things like this



    public class ChatController : Controller
{
IRepository<Conversation> conversationRepository;

public ChatController(IRepository<Conversation> conversationRepository)
{
this.conversationRepository = conversationRepository;
}

public ActionResult Index()
{
ViewData["Conversations"] = conversationRepository
.Items
.OrderBy(c => c.Name)
.ToList();
return RenderView("ConversationList");
}
}


But where does IRepository<T> come from? We'll see that one next time with the LinqToSql stuff.



For now everything is in a Google code repository here: http://code.google.com/p/wolfbyte/ so you'll need to crank out Subversion to get at it. It's all licensed under the new BSD license so do with it as you need to. As soon as my sample is finished I'll post the whole lot as a Zip-file.



P.S. As soon as the house has settled and we move in there will be pictures. Well, as soon as I can get rid of the pink carpet anyway :)


mvc3asp-netopen-sourceaspnetmvc
Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History

Comments

No comments yet. Be the first!

No new comments are allowed on this post.