Learning in Public A collaborative learning site

Off-topic: Experiencing Orchard

Yesterday, an announcement was posted that the Orchard Project is now part of the CodePlex Foundation(somehow we’re not supposed to confuse this with Microsoft’s CodePlex.com). Orchard is, as the site describes:

…a free, open source, community-focused project aimed at delivering applications and reusable components on the ASP.NET platform.

Orchard has been on my radar for a bit. I’ve known Erik Porter for many years now (before either of us came to Microsoft). I’ve watched him work on Oxite (which my current un-updated ‘blog’ is running on now) and even created a skin for that platform. When Erik moved over to start working on Orchard, I took notice. That said, I have been very interested in where this is heading in a very competitive market.

The thing that makes Orchard interesting, however, is that it isn’t meant to compete with other CM systems in the market today. Sure, Orchard will have a reference implementation of a CMS system, but the main interesting thing Orchard brings to the table is an extensible architecture that lets you improve an existing CMS or build a new one from scratch. I could wax poetic and try to define the system myself, but that would be wrong. I’m not on the team, and I don’t know everything there is to know. To be honest, I don’t even know if the Orchard team knows what is in store for them.

My interest brought me to download the code and start looking at it in depth. Once the MVC series is complete, I fully intend to go back and do some Orchard videos too — hopefully the APIs will be a bit more baked for that effort to make sense.

Still, I thought I would blog about it now as it seems very interesting to me. If you are interested in checking it out for yourself, I encourage you to follow the instructions for titled “How to Get Involved” on the CodePlex project page, then read ahead.

Inspecting the Code

The first thing I wanted to do was see how Orchard starts. The profound answer people always give when you ask where to start is, “Start from the beginning, of course.” Looking at the source code in Visual Studio, the beginning isn’t explicitly noted:

Luckily, I happen to know where the beginning of most ASP.NET -based applications is: in the Application_Start() method of the global.asax.cs file.

protected void Application_Start() {
            RegisterRoutes(RouteTable.Routes);
            _host = OrchardStarter.CreateHost(MvcSingletons);
            _host.Initialize();
            // ...
}

Discovering Dependencies

The first thing that happens when we look at the Application_Start method in global.asax.cs is that the application registers routes that will be used. We’ll dig into how this works in our next ASP.NET MVC videodiscussion. Orchard’s unique works right after that. We see that Orchard get’s a reference to an IOrchardHost interface through a static method named CreateHost(). Obviously that interface has to point to something concrete, so I dug into CreateHost to see what it does. Of course this method was very lightweight and called a private method named CreateHostContainer which in turn returned an Autofac.IContainer interface.

This is our first interesting dependency that Orchard is taking — strangely enough that dependency is on something called an “Inversion of Control” (IoC) container. Once again, we’ll cover IoC in our ASP.NET MVC series. For now, just understand that Orchard is using an IoC container called Autofacto resolve interfaces to concrete classes. The benefit of this is that we can “inject” functionality into Orchard using Autofac. Orchard doesn’t need to know how we implement interfaces — just how we are interacting with them. We can even “inject” dependent assemblies into Orchard in order to use the concrete classes our interfaces represent. If this is confusing, just move on for now.  I’m using Orchard as an excuse to introduce you to concepts we will cover in our video series!

Inspecting the Blog Controller

Now we have a little information about some of the underpinnings of Orchard. Let’s take what we know already about controllers in an MVC application to work while we investigate further. I can see just from running the application that the BlogController  is one that has been worked on a bit. If we scroll back up in the project and look under the “packages” solution folder, we should see the “Orchard.Blogs” project. This project is an MVC application in and of itself. It has models, views, and controllers. I decided to dive into the BlogController.cs file. You should already be familiar with the basics of controllers if you have done the first three videos on this site. You’ll see several methods return ActionResult class instances rather than the ViewResult which we’ve been using so far. Don’t let that bother you either. Once again, we’ll get into that in another post!

Looking at the constructor for this controller, I see that Autofac is “injecting” a dependency on whatever is registered to return an ISessionLocatorreference. Naturally I want to see what is registered for ISessionLocator. I did a search in the solution for the interface name and came across the only method in DataModule.cs called “Load()“.

protected override void Load(ContainerBuilder builder) {
            builder.RegisterGeneric(typeof (Repository<>)).As(typeof (IRepository<>)).FactoryScoped();
            builder.Register<HackSessionLocator>().As<ISessionLocator>().ContainerScoped();
}

This method registers the “HackSessionLocator” class as the concrete implementation for ISessionLocator. This is where we start finding more of the plumbing dependencies that Orchard is taking.

HackSessionLocator

As the name HackSessionLocator indicates, this is likely just something thrown together to get plumbing working so the team can work on the rest of the project. It appears from this that the team decided to use a number of hard-coded dependencies to get the project moving. I can imagine that a real session locator will not be so, well, hackish. The great thing about using dependency injection via the Autofac IoC container is that all they need to do is write a new session locator class, then register the new locator instead of HackSessionLocator. For now, I wanted to take note of a few other decisions the teams seems to have made in the short term.

If you notice the namespaces that the HackSessionLocator uses, you’ll find references to NHibernate and FluentNHibernate. If you aren’t familiar with these namespaces, NHibernateis a .NET object-relational mapper (ORM) – again, another major future topic of our MVC series. An ORM framework like NHibernate maps data in a relational database to .NET types that can be easily consumed by your application. The best part is that your application doesn’t need to know what database you are mapping to. The framework does all the magic of mapping data from a repository to a model, and allows you to execute typical CRUD (Create, Read, Update, Delete) methods on that data – again without knowledge of how that functionality is implemented by the repository under the hood. FluentNHibernateis simply another layer that allows you to configure NHibernate without XML files.

Wrapping Up and Next Steps

This was just a sneak look at Orchard. We haven’t even gotten into the details yet. There is a lot more goodness happening in here. We’ve seen how Orchard is separating concerns very well using tools like Autofac and NHibernate. At some point, we’ll dig in deeper, but until Orchard is close to a first release, I hesitate to go too much further. I’m personally going to create my own content types and try doing some dev work in these early stages so I can give the team feedback. I hope that you will too as you feel comfortable.