Storm in a Jar » .NET Framework

Supporting multiple databases using the Unit of Work and Repository patterns

Rob Jones — Tue, 13 Dec 2011 12:46:26 +0000

You might have read my previous entries about the Unit of Work and Repository design patterns. If not, you might want to check them out before reading the rest of this article.

A little while ago, I had to redesign the Unit of Work and Repository structure in a project at work. Naturally, I was quite happy to do so, as I have done a lot of research and development work on this topic already.

A requirement was that the unit of work should be able to work with multiple databases. I figured that the generic approach as described in my previous articles would work just as well to solve this issue. I was rather pleased when I discovered that the sample code, provided as download in one of my previous articles, worked with only a few modifications.

Another thing of beauty – which is slightly off-topic, but deserves to be mentioned – was to see the code working through a different inversion of control container. My code always used Castle Windsor for IoC and DI, but the project at work uses StructureMap. I had a little nerdgasm when I saw my code working in a completely different environment; it really gave me the feeling that I had written some very versatile code that can be implemented in different scenarios with very little effort!

On to the actual code now…

The project uses Entity Framework 4.1 and has no requirements to support different ORM tools. This allowed me to make a few minor code changes to facilitate EF 4.1 a little better.

Let’s start with the unit of work interface:

public interface IUnitOfWork : IDisposable
{
    void Commit();
}

/// 
/// Generic unit of work interface for different DbContext objects.
/// 
/// 
/// Keyword "out" is specified for the generic parameter
/// to allow casting (covariance).
/// 
/// Concrete DbContext type.
public interface IUnitOfWork : IUnitOfWork
   where TContext : DbContext
{
    TContext Context { get; }
}

Very little changes in the code here. An out-keyword was added to the generic TContext parameter and an added restriction that TContext should always be of type DbContext (Entity Framework 4.1 specific change).

The only other change was done in the abstract Repository class:

public abstract class Repository : IRepository
    where TEntity : class
{
    private IUnitOfWork unitOfWork;
    private readonly IDbSet entitySet;

    /// 
    /// Creates a new repository.
    /// 
    /// The unit of work to use.
    public Repository(IUnitOfWork unitOfWork)
    {
        this.unitOfWork = (IUnitOfWork)unitOfWork;
        this.entitySet = this.unitOfWork.Context.Set();
    }
}

This code was modified to be able to cast the IUnitOfWork to an IUnitOfWork. This is another change specific for EF 4.1 to allow me to access the context and create an entity set.

And finally, the StructureMap registries tie everything together when bootstrapping the application:

    ForConcreteType();

    ForConcreteType();

    ForConcreteType>()
        .Configure
        .Ctor();

    ForConcreteType>()
        .Configure
        .Ctor();

    For()
        .Use()
        .Ctor()
        .Is>();

    For()
        .Use()
        .Ctor()
        .Is>();

I’m not an expert on StructureMap, so I’m not sure if this is the most efficient way to go, but here I define the concrete context objects for the databases as well as which context to use when initializing the repositories.

Hopefully this, combined with my previous posts, is enough to let you figure out the total picture on your own. If there actually is demand for another sample project, let me know in the comments and I’ll see if I can free up some time to make one.

Rediscovering Telerik

Rob Jones — Mon, 22 Aug 2011 08:26:37 +0000

I’ve recently switched to a new employer and only now I realize how much I loved working with the Telerik‘s product suite. I no longer have access to all the goodies Telerik offers. My previous two employers had licenses for either the Ultimate Collection for .NET or just the ASP.NET AJAX components. That’s roughly five to six years of developing in .NET, with Telerik components! Trust me, it’s rather unpleasant having to revert back to default controls!

From this point of view I looked at Telerik again. What can they still offer me at this point, since I can’t afford to buy any licenses. In fact, I was pleasantly surprised! I knew they had some free tools, but I never quite realized which. I already knew of JustDecompile and the ASP.NET MVC components. To my delight, I discovered a free version of OpenAccess ORM! I will admit that this severely limits the toolbox that I got used to, but it’s still a pretty awesome toolbox to use.

A free version of OpenAccess is just a godsend! Due to previously bad experiences with Entity Framework, I didn’t want to go back to using that. Nor did I want to continue using NHibernate, even though it can do everything I can possibly think of… it’s always a pain in the backside to actually get it done. Sure, OpenAccess has it’s quirks and limitations, but at least there’s a company supporting their product actively and let’s not forget about the community contributions!

I don’t have much experience developing with the ASP.NET MVC framework, but knowing that Telerik’s controls are free to use might make me look into this option. I quite like the looks of MVC3 with the Razor view engine; it’s lifted a few of my main objections to working with the MVC framework. So, again… here I have an opportunity to continue to build applications with the help of an awesome control suite.

In fact, not having access to all the goodies that I’ve used for all these years might make me a better developer! I’m forced to reconsider my options and perhaps learn new techniques and start using those.

My thanks to the Telerik team: you’re not just pushing yourselves with every release, but pushing me as well to stay on top of my game! Continue the awesome work!

Unit of Work & Repository support for multiple frameworks, part 2

Rob Jones — Sun, 13 Mar 2011 11:12:40 +0000

Quite a while ago I made a post about creating a unit of work and a repository that would allow me to swap between Entity Framework and NHibernate relatively quickly. In the past few weeks (or have they turned into months already?!), I received a few requests for a sample project to show how this can be implemented and used in a real world scenario. I sat down to work on it this weekend and I’m happy to say I managed to finish a working sample project.

Click here to download the sample project.

Keep in mind that I won’t take responsibility for any of this code if you decide to deploy it in a production environment. However, feel free to use this code for your own projects and modify it to suit your own needs. It’s only meant to provide a sample and show a way how to implement repositories that are not dependant on a specific type of framework.

I truly hope my efforts are appreciated and that it can be a learning experience for everyone who requested a sample project on this issue!

Everything you need should be included in the package.

Binaries

Castle Windsor 2.5.2
Inversion of Control and Dependency Injection container.
NHibernate 3.1.0
ORM framework based on the famous Hibernate for Java.

Documentation

Read Me (How To).docx
Explains how to get started with the sample project and what needs to be done to switch between Entity Framework and NHibernate
Technical documentation.docx
It’s not really technical documentation as such. Just a few points to note. I haven’t been able to find the time to sit down and properly document things. I will do so if it proves to be necessary, but I think things are easy enough to understand for the average smart developer!

Source

All projects and source-code can be seen by opening up the MultiRepository solution file.

NHibernate: Association references unmapped class

Rob Jones — Mon, 07 Mar 2011 13:30:06 +0000

If this exception message pops up when using NHibernate, make sure to check the following:

The mapping file is set as embedded resource;
The name of the mapping file ends with .hbm.xml instead of .xml;

I just spent two days wondering why this message kept occurring. Turns out that I had named my mapping file: SomeMapping.xml, instead of SomeMapping.hbm.xml.

Wouldn’t it be nice to have compile time checks on NHibernate mappings?! Wait… there is! It’s called Fluent NHibernate and we don’t use it here at work. ARGH! Perhaps I should see if I can spend a little time investigating how much effort it is to rewrite all the mappings using Fluent…

NHibernate mappings

Rob Jones — Thu, 03 Mar 2011 15:27:00 +0000

I genuinely hate them! If someone knows a decent graphical editor similar to Entity Framework’s designer, please let me know!

The magic of Castle Windsor!

Rob Jones — Thu, 24 Feb 2011 11:36:04 +0000

A while ago I wrote a few articles on this site about exposing Castle Windsor to your application. For some reason that caught the attention of Krzysztof Koźmic and Mark Seemann. In short they felt I was doing it all wrong! Which led to a follow up article. Fair enough, I was new to the whole principle of Inversion of Control and Dependency Injection, so I assumed they were in the know and were probably correct in… correcting me!

Since then I’ve been fiddling around with it in my spare time, trying to set up an architecture that would allow me to use Castle Windsor as it was intended. Unfortunately, my spare time is a little limited, so it took me a few months in total to come up with something a little more structured and streamlined. However, this week I got to the point where I said to myself: “Wow, now that’s cool!”

I’m not quite sure where to start. Perhaps it’s best to give some background information first.

I was looking for a clean solution to implement a Model View Presenter architecture in my application. Ideally this would be coded into a framework that I could use for any other project in the future. In fact, I already posted about modular web applications back in April last year! It addressed the Composite Web Application Block that provided the solution that I was looking for. After playing around with it however, I found it was very cumbersome to work with. Although, with the power of hindsight, that could have been due to my lack of knowledge of IoC and DI.

I ended up building my own framework, heavily inspired by the ideas behind the Composite Web Application Block. At first I managed to get along just fine without any form of inversion of control or dependency injection. The further I got down the road, the more obvious it became that, while possible, the code became cluttered and no longer felt as clean as I wanted. At this point we decided in the office to continue down the road of using as little inversion of control and dependency injection as we could get away with. However, in my spare time I decided to research at home how to utilise the capabilities of Castle Windsor to achieve that clean, loosely coupled design that would make my life so easy!

It took a bit of experimenting, but I’m glad I’ve done so. I feel I have a much better understanding of the principles of Inversion of Control and Dependency Injection as well as how to use Castle Windsor to help me implement this.

Now that I’ve given a little introduction to the background information, it’s time to look at a little class diagram. I’ve simplified it for the sake of example. It clearly shows five distinctly separate ‘layers’.

(Click to enlarge)

Let’s quickly go over the things you see in this diagram.

Unit of work;
This can be an NHibernate Session or an Entity Framework ObjectContext.
Repository;
The repositories do all the work of querying the context and return objects with data.
Controller;
The controller communicates with repositories and performs validations if needed. The reason for adding a controller is to allow for extending the architecture with web services later. A web service doesn’t know anything about presenters and views and is only interested in data and validations.
Presenter;
The presenter asks the controller to perform a task and prepares the data for the view.
View;
The view presents the data on the screen (can be a web form, win form, etc).

This is the point where Castle Windsor starts to come in.

As the name suggests, WebFormView is a web form. Within Visual Studio you’d see it as WebFormView.aspx in the Solution Explorer. It’s just a normal web page. The only thing that differs from “normal” is that the code-behind implements the IView interface. The rest of the system is tied together by using one of the most fundamental principles of object oriented programming: composition.

All I need to do now is to tell Castle Windsor which concrete implementations should be injected in all those classes. This is done through configuration. My personal preference is using XML files to configure, but feel free to use whichever method you prefer. For example:



  
    
    
    

    
    
      
        ${context.ef4}
      
    

    
    
      
        ${unitofwork.ef4}
      
    
    
      
        ${unitofwork.ef4}
      
    

    
    
      
        
          
            ${repositories.defaultdummy}
            ${repositories.otherdummy}
          
        

      
    

    
    
      
        ${controllers.default}

If you have studied the XML configuration for a moment, you will notice that I am not specifying a view parameter in the configuration for the presenter component. However, the class diagram clearly shows we need to have a view! This is because it will be detected dynamically on run-time which view needs to be given as a parameter.

I can feel you already wondering how this works. But, before I can tell you, I will have to add a few more tidbits of information to glue everything together.

The view is the absolute starting point. When sending a request to the server to load WebFormView.aspx (or any other web page), I need to figure out which presenter to resolve. To prevent having to write the same code on each and every page, I’ve adopted a naming convention strategy that allows me to figure this out “on the fly” in a base page class:

The Id of the component within the Castle Windsor configuration should be able to be deducted from the root application path of the web page that has been requested.

Here’s a few examples to show what I mean:

url: http://localhost/default.aspx
id: presenters.default

url: http://localhost/subfolder/default.aspx
id: presenters.subfolder.default

url: http://localhost/MyAppRoot/default.aspx
id: presenters.default

url: http://localhost/MyAppRoot/subfolder/default.aspx
id: presenters.subfolder.default

Once I figured out that I could resolve presenters based on a naming convention, the code was pretty easy to write:

public class Page : System.Web.UI.Page, IView
{
    protected IPresenter presenter;

    /// 
    /// Initializes the page. In this case it resolves our presenter class
    /// through Castle Windsor.
    /// 
    /// 
    /// 
    protected virtual void Page_Init(object sender, EventArgs e)
    {
        string windsorKey = "";

        try
        {
            // Determine which presenter to resolve.
            int rootPathIndex = Request.Path.IndexOf(Request.ApplicationPath);
            int dotAspxIndex = Request.Path.IndexOf(".aspx");

            windsorKey = Request.Path
                .Remove(dotAspxIndex, 5)                                // strip .aspx
                .Remove(rootPathIndex, Request.ApplicationPath.Length)  // strip the root
                .Replace("/", ".")                                      // replace slash
                .ToLower();                                             // to lowercase

            // Finally create the proper windsor key.
            windsorKey = (windsorKey.StartsWith("."))
                ? String.Format("presenters{0}", windsorKey)
                : String.Format("presenters.{0}", windsorKey);

            // Let the presenter factory take care of creating the presenter.
            // Castle Windsor will make sure all dependencies will be resolved.
            this.presenter = HttpApplication.PresenterFactory.Create(windsorKey, this);
        }
        catch (Exception ex)
        {
            string message = String.Format(
                "Error trying to resolve presenter: {0}. See InnerException for details",
                windsorKey);

            throw new FrameworkException(message, ex);
        }
    }
}

Pretty neat, huh? But, wait! There’s something new in this code! Have you spotted it? I’ll highlight it for you, just in case:

// Let the presenter factory take care of creating the presenter.
// Castle Windsor will make sure all dependencies will be resolved.
this.presenter = HttpApplication.PresenterFactory.Create(windsorKey, this);

Up until now I’ve not spoken about the presenter factory yet. One of the things that I had a truly hard time to understand when trying to figure this out was the so-called Three Calls Pattern. When I read through that page for the very first time, I got a proper ‘what the fuck’ feeling! Once I figured it out, it was actually fairly straight forward. The mistake I made earlier was exposing the container to the application to resolve objects. In fact, if the system is designed properly, I found I don’t really need access to the container at all.

In short it means: make sure to call Install() on the container just once when the application starts, resolve one object that resolves everything else through dependency injection (hint: remember how the XML configuration looks) and finally release the object to free up memory. In my own situation it means that I install the container and resolve the PresenterFactory during Application_Start in the HttpApplication of my framework.

public class HttpApplication : System.Web.HttpApplication
{
    public static IPresenterFactory PresenterFactory;

    protected virtual void Application_Start(object sender, EventArgs e)
    {
        // Retrieve modules from (web) application configuration.
        ModuleSection moduleConfigSection = (ModuleSection)
            ConfigurationManager.GetSection("moduleSettings/modules");

        if (moduleConfigSection == null)
        {
            // Config secion not found, throw detailed exception message.
            throw new FrameworkException(
                "Please add module configuration to the application configuration "
                + "file: \n\r\n\r"
                + "\n\r"
                + "     \n\r"
                + ""
            );
        }

        // Initialize the required/ specified modules.
        ModuleInitializer.Initialize(moduleConfigSection.Modules);

        // Module initialization will have registered all necessary
        // windsor components, it should be safe to call Install()
        Windsor.Install();

        // Windsor installed, resolve the presenter factory.
        PresenterFactory = Windsor.Resolve();
    }
}

Castle Windsor has a feature called typed factory facilities. This is actually pretty cool. I can use this to create a PresenterFactory interface through which I can resolve a presenter. Castle Windsor is smart enough to figure out all the nitty gritty details for me. I only specify the interface and tell the configuration to use the typed facility factory and that’s it!

public interface IPresenterFactory
{
    IPresenter Create(string name, IView view);
}

To create a presenter, I need to specify two parameters: the name of the presenter to resolve and the view object to inject. This is exactly what you saw me do earlier, when calling the PresenterFactory from the Page_Init! However, there is a small downside… this doesn’t work out of the box. Castle Windsor will have to understand these parameters. This can be done by writing a custom component selector:

public class PresenterTypedFactoryComponentSelector : DefaultTypedFactoryComponentSelector
{
    protected override string GetComponentName(MethodInfo method, object[] arguments)
    {
        if (method.Name == "Create"
            && arguments.Length == 2
            && arguments[0] is string)
        {
            return (string)arguments[0];
        }

        return base.GetComponentName(method, arguments);
    }
}

It looks a little intimidating, but all this does is override Windsor’s method to get the component. It checks if the calling method name equals Create and if the method was called using two parameters and the first parameter needs to be a string. I could have done some additional checks, such as checking if the second parameter is of the type IView, but I didn’t think this was too big of an issue.

Now that all the missing pieces have been assembled, it’s time to let Castle Windsor know that we’d like to use a typed factory facility with our own home-made custom component selector. Simply open up the configuration file and insert at the top:

At this point everything is done! Let me summarize what I’ve achieved with all this code and configuration:

Using the Three Calls Pattern to automatically resolve a presenter through the PresenterFactory by looking at the URL of the requested web page. Not only the presenter is resolved, its controllers, repositories and unit of work are automatically resolved and injected. Even better, the unit of work has a parameter to resolve the object context of the entity framework! There’s never a need to look back to instantiate things myself (slight detail: remember to implement IDisposable in the unit of work to dispose of the context when the unit of work gets disposed)!

Let’s see if we can sum up the advantages of using this approach:

Flexible due to configuration;
Easy to add new functionalities because the system is loosely coupled and isn’t dependant on concrete implementations;
Allows the use of the MVP design pattern to create a web forms application;
Allows for injecting mock classes to help unit testing;

I can easily see that one of the biggest disadvantages of this approach is that it might be hard to understand for developers who aren’t familiar yet with inversion of control and dependency injection and who have never worked with IoC containers such as Castle Windsor.

Stylesheets, stylesheets, stylesheets… ARGH!

Rob Jones — Wed, 19 Jan 2011 10:16:14 +0000

Ever had a problem in your code where you ended up banging your head against a brick wall for a number of days? To make it better, once solved the solution appeared to be so laughably easy that it’s kind of embarrassing to explain why it took you so long to notice the mistake? Of course you have! Every developer has moments like that. Everyone denying this is a big, fat liar! Today’s post will be about my own little… problem.

I was trying to add a stylesheet to the RadStyleSheetManager during an AJAX-postback. Sounds pretty easy, right? That’s what I thought too… Wrong! Or, as it turns out, it was after all.

I had a custom UserControl that includes a stylesheet during the OnInit event. So far, so good. I had even seen it work on another page within the project. When I tried to use the same UserControl on a different page, it looked as if the included styles didn’t get picked up. The control itself was working fine and displaying all data, except it seemed to be missing all the mark-up. That must automatically mean the stylesheet didn’t get included, right? Right?!

Turns out that the whole problem was that the HTML on the UserControl used classes that were specified in a different stylesheet than the one being included on the OnInit event! Yeah, that should have been one of the first things to check when I discovered it wasn’t working on my page, but was working properly on another. However, for some reason I didn’t check and ended up being a bit frustrated with what seemed an illogical problem while, in fact, it wasn’t a problem at all. Just stupidity on my part.

To make things even more hilarious, I had created a support ticket at Telerik. In the ticket I had included a sample project so that the folks at Telerik Support would easily be able to reproduce my problem and help me out. Unwittingly I had created a class library project called “External” and included the stylesheet in there as an embedded resource. I had quickly tested my sample project and being satisfied that the problem was being reproduced, I attached it to the support ticket.

The response to the ticket was, to me, very surprising. Apparently there is a bug in the current Telerik release that causes a problem where stylesheets are not picked up from an assembly called ‘External’. External is a reserved keyword and due to a little error in Telerik’s software, the stylesheet didn’t get picked up from the assembly. I even got awarded 500 Telerik points for reporting a bug in their software! Awesome!

However, it got me thinking… the project that originally caused this problem for me didn’t have any assemblies called ‘External’. How come I’m having this problem then? I started digging around and that’s when I found out I had included the other stylesheet. Oops! Pretty embarrassing, right? I do feel a little better for having contributed, albeit unwittingly and in a very tiny way, to improving the quality of the Telerik components!

Castle Windsor: exposing the container? “Not, at all”

Rob Jones — Wed, 29 Sep 2010 07:36:14 +0000

It looks as if yesterday’s entry about Castle Windsor went all over the Internet. Somehow it also got to the attention of Krzysztof Koźmic. He seems a rather smart fellow, being project leader of Castle Core and Castle DynamicProxy! He made a tweet in reference to my entry:

http://bit.ly/aSmqFy “So how do I expose my container to the application?” <– not, at all

Very helpful indeed! I will immediately accept that Krzysztof is a lot smarter than I am and that he knows what he’s on about. As eager as I am to learn new things, I’m hoping this entry will come to his attention as well. Secretly, I’m hoping that he will share his wisdom to enlighten the ignorant (aka. myself). If at all possible, in slightly more detail.

Let’s start with what I think I know about Castle Windsor. It has a container that, amongst other things, provides Inversion of Control and Depedency Injection. Within the container there are components that can be resolved. If the components have dependencies on other components, Castle Windsor is smart enough to detect and inject them.

From here on things start to get confusing for me. In my ignorance I had assumed that at some point in my application I could give the container a poke to resolve an object for me. I would then use the object for whatever purpose it was created and release it after. If I don’t expose some way to resolve objects from the container, how the heck am I supposed to get them out of there?

From the Three Calls Pattern I had assumed that it’s good practice to install the container at only one point in my application, rather than creating a new container whenever I’d want an object. This made perfect sense to me. What doesn’t make sense to me is Call Two; resolving the root component. Thankfully there was a little notice after that this is not a very strict rule at all and resolve can be called when I have multiple root components.

Imagine the following XML configuration to install the container:

Why would I want to resolve any of these objects immediately after installing the container? I want to use these objects at a later stage in my application (e.g. when I actually need them). So again, if I don’t expose some way to resolve objects from the container, how am I supposed to get one? I see absolutely no point in resolving the objects straight after installation where I simply don’t need them.

If it is considered bad practice to want to resolve an object on-the-fly whenever and wherever I want, I will freely admit that I’ve totally missed the point of Castle Windsor and will humbly ask for someone to enlighten me with a practical real-world example of how things “should” be done!

Castle Windsor: exposing a container to an application

Rob Jones — Tue, 28 Sep 2010 07:58:49 +0000

A while ago I wrote multiple entries about generic factories and repositories.

The ObjectFactory I created there was loosely based around the ideas of Inversion of Control. I’ve learned many new things by now and apparently it’s a reasonably common journey for anyone new to IoC to start out with a little ObjectFactory class and move on towards more advanced Inversion of Control and Dependency Injection containers, such as Castle Windsor.

Making the transition to Castle Windsor has been a bit of a frustrating one. There’s plenty of information to find on the Internet, but everywhere I looked it was only the basic sample of registering and resolving objects, using facilities and so on. The frustrating part was that none of the articles I could find dealt with using the IWindsorContainer in a large enterprise architecture.

A very practical question I had almost immediately after toying with the basics was: “So how do I expose my container to the application?” I found the Three Calls Pattern article on the Castle Project Wiki. Not that it is extremely helpful, it’s good to know how the Windsor developers meant the container to be used. It still didn’t answer my question though. I was nowhere closer to knowing how to expose my container. A lot of articles simply make the container available through a static property in the Global.asax. I’m sure this will work splendidly if the only thing I would need to worry about was a single web application project. However, I have an entire framework consisting of multiple class libraries and a client that consists of multiple web application projects and class libraries as well!

In the end, as is so often the case, the answer was rather simple: use the Singleton design pattern to expose a single container to the entire application.

using System;
using System.Collections.Generic;
using System.Linq;
using Castle.Core.Resource;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Castle.Windsor.Installer;

namespace Storminajar.Framework.Services
{
    public static class WindsorService
    {
        private static bool isInstalled = false;
        private static object locker = new object();
        private static IWindsorContainer container = new WindsorContainer();
        private static IList installers =
            new List();       

        /// 
        /// Adds installer to the container.
        /// 
        /// 
        public static void AddInstaller(IWindsorInstaller installer)
        {
            lock (locker)
            {
                if (!installers.Contains(installer))
                {
                    installers.Add(installer);
                }
            }
        }

        /// 
        /// Adds installer to the container using embedded xml configuration file.
        /// 
        /// Assembly containing the configuration file.
        /// The name of the configuration file;
        /// path must be included (e.g.: Configuration/Components.xml).
        public static void AddAssemblyResourceInstaller(string assembly, string filename)
        {
            string assemblyResourcePath =
                String.Format("assembly://{0}/{1}", assembly, filename);

            IWindsorInstaller installer =
                Configuration.FromXml(new AssemblyResource(assemblyResourcePath));

            lock (locker)
            {
                if (!installers.Contains(installer))
                {
                    installers.Add(installer);
                }
            }
        }

        /// 
        /// Installs container.
        /// 
        public static void Install()
        {
            if (!isInstalled)
            {
                if (installers.Count > 0)
                {
                    container.Install(installers.ToArray());
                    isInstalled = true;
                }
                else
                {
                    throw new Exception(
                        "Can not install container: no installers have been added.");
                }
            }
            else
            {
                throw new Exception("Container is already installed! "
                    + "Clear() needs to be called before you can "
                    + "(re)install container.");
            }
        }

        /// 
        /// Clears the container.
        /// 
        public static void Clear()
        {
            container.Dispose();
            container = new WindsorContainer();
            isInstalled = false;
        }

        /// 
        /// Resolves object from container.
        /// 
        /// Type of object to resolve.
        /// 
        public static T Resolve()
        {
            return container.Resolve();
        }

        /// 
        /// Releases object fron container and frees up resources.
        /// 
        /// 
        public static void Release(object instance)
        {
            container.Release(instance);
        }

        /// 
        /// Adds a component to the container.
        /// 
        /// Type of object.
        /// The instance of the object to add.
        public static void Register(T instance)
        {
            container.Register(
                Component.For().Instance(instance));
        }
    }
}

I have now successfully exposed the IWindsorContainer to my application. When I’d like to use it to I can simply call any of the methods from anywhere in my code and not worry about a thing!

I will probably write a follow-up later, showing how I used Castle Windsor together with NHibernate conversations and repositories.

Letting your UnitOfWork & Repositories support multiple frameworks

Rob Jones — Mon, 30 Aug 2010 14:30:20 +0000

On popular demand, part 2 with a sample project can be found here.

A little while ago I found myself in a situation where I had to replace Microsoft’s Entity Framework with NHibernate. I had figured this wouldn’t be too much of a problem! I had neatly used a Unit of Work and Repository implementation for all my data access needs, so I felt pretty secure in the knowledge that I should be able to switch quite quickly between the two.

Eventually I did, it wasn’t near as quick as I had initially thought though. I discovered that all these articles on the internet describe how to implement a Unit of Work for a single framework! The one I had written was focused solely on the Entity Framework and was pretty much useless for NHibernate. Dismayed, I decided to scrap what I had and start over with the design. This time specifically keeping in mind that I might want to be able to swap between the two at some point in the future.

Let’s start at the beginning. To be able to create a common interface for my repositories, and a common way to interact with my repositories, I decided I would need a common UnitOfWork interface as well. It doesn’t have to do anything, as long as it gives me the ability to cast my objects back and forth.

/// 
/// Doesn't do anything besides providing a common interface.
/// 
/// 
/// TODO: Distinguish common functionality later and implement it!
/// 
public interface IUnitOfWork : IDisposable
{
}

Well, that was easy! I now have my interface. I can already picture the frown on your face. After all, what’s the bloody point of an interface without methods?! Admittedly, not much at first sight. Bear with me and you’ll find out why I’ve done this.

The following thing I needed was some sort of interface that allows me to specify the type of context for the Unit of Work. Aha! I smell generics!

/// 
/// Provides a generic interface for a Unit of Work.
/// 
public interface IUnitOfWork : IUnitOfWork
{
    TContext Context;
    void SaveChanges(TEntity entity);
    void CancelChanges();
}

Let’s not worry about the specifics yet. The only thing I am worried about here is providing a generic Unit of Work. This way I can simply define a Unit of Work and give the type of the context along with it, for example the ObjectContext for EF4 and ISession for NHibernate! Pretty neat We’re not done yet though. Because the Entity Framework and NHibernate are so different from each other, I decided to implement specific interface for each of those as well. I can imagine different methods might be useful when working with one or the other.

/// 
/// Implement Unit of Work specifically for Entity Framework.
/// Details can be implemented later.
/// 
public interface IEFUnitOfWork : IUnitOfWork
{
}

/// 
/// Implement Unit of Work specifically for NHibernate.
/// Details can be implemented later.
/// 
public interface INHUnitOfWork: IUnitOfWork
{
}

That’s it! I have now defined the interfaces that will help me with building a common repository interface and a common way of using concrete repositories. Let’s go and have a look at the repositories. Here’s a simple interface for the repositories, it only has three methods for now, but of course you can expand on that to your own liking.

public interface IRepository
{
    T GetFirst(Expression> where,
        Expression>[] eagerFetch);

    IEnumerable GetMany(Expression> where,
        Expression>[] eagerFetch);

    IEnumerable GetAll(Expression>[] eagerFetch);
}

I can now use this interface to implement different base repositories for Entity Framework as well as NHibernate.

I will start by showing the implementation for the Entity Framework. If you pay close attention to it, you will see that the AddIncludesToObjectSet() method uses a generic Include method. This is an extension method on top of the ObjectQuery object. I’ll probably explain this in a follow-up post!

public abstract class Repository : IRepository where T : class
{
    private IEFUnitOfWork unitOfWork;
    private ObjectContext objectContext;
    private ObjectQuery objectSet;

    /// 
    /// Constructs an EntityFramework repository.
    /// 
    /// Unit of Work for repository to work with.
    public Repository(IUnitOfWork unitOfWork)
    {
        this.unitOfWork = (IEFUnitOfWork)unitOfWork;
        this.objectContext = this.unitOfWork.Context;
    }

    public virtual T GetFirst(Expression> where,
        Expression>[] eagerFetch)
    {
        this.objectSet = this.objectContext.CreateObjectSet();
        AddIncludesToObjectSet(eagerFetch);

        return this.objectSet
            .Where(where)
            .FirstOrDefault();
    }

    public virtual IEnumerable GetMany(Expression> where,
        Expression>[] eagerFetch)
    {
        this.objectSet = this.objectContext.CreateObjectSet();
        AddIncludesToObjectSet(eagerFetch);

        return this.objectSet
            .Where(where)
            .AsEnumerable();
    }

    public virtual IEnumerable GetAll(Expression>[] eagerFetch)
    {
        this.objectSet = this.objectContext.CreateObjectSet();
        AddIncludesToObjectSet(eagerFetch);

        return this.objectSet
            .AsEnumerable();
    }

    private void AddIncludesToObjectSet(Expression>[] eagerFetch)
    {
        if (eagerFetch != null)
        {
            foreach (Expression> fetch in eagerFetch)
            {
                this.objectSet.Include(fetch);
            }
        }
    }
}

For the NHibernate repository I came up with the following code below this paragraph. Keep in mind that I’ve used the alpha version of NHibernate 3.0 and therefor I’m able to use the NHibernate.Linq namespace easily and call the Query() method on the ISession object!

public abstract class Repository : IRepository where T : class
{
    private INHUnitOfWork unitOfWork;
    private ISession session;

    public Repository(IUnitOfWork unitOfWork)
    {
        this.unitOfWork = (INHUnitOfWork)unitOfWork;
        this.session = this.unitOfWork.Context.SessionFactory.GetCurrentSession();
    }

    public virtual T GetFirst(Expression> where,
        Expression>[] eagerFetch)
    {
        IQueryable query = this.session
            .Query()
            .Where(where);

        query = AddFetchMode(query, eagerFetch);

        return query.FirstOrDefault();
    }

    public virtual IEnumerable GetMany(Expression> where,
        Expression>[] eagerFetch)
    {
        IQueryable query = this.session
            .Query()
            .Where(where);

        query = AddFetchMode(query, eagerFetch);

        return query.AsEnumerable();
    }

    public virtual IEnumerable GetAll(Expression>[] eagerFetch)
    {
        IQueryable query = this.session.Query();
        query = AddFetchMode(query, eagerFetch); 

        return query.AsEnumerable();
    }

    private IQueryable AddFetchMode(IQueryable queryable,
        Expression>[] eagerFetch)
    {
        if (eagerFetch != null)
        {
            foreach (Expression> fetch in eagerFetch)
            {
                queryable = queryable.Fetch(fetch);
            }
        }

        return queryable;
    }
}

What have I achieved after all this trouble? That I can write our repositories once and never change them, regardless if I’m working with NHibernate or Entity Framework! Also, this is the part where my useless interface without methods comes into play! I know I have an IUnitOfWork object and I can simply pass it along to the constructor of this repository, regardless of the fact if it is an INHUnitOfWork or IEFUnitOfWork. Perhaps this part can still use a bit of work with type safety, so that there are no accidents with passing along a IEFUnitOfWork to a repository that is expecting a INHUnitOfWork!

public class ConcreteRepository : Repository, IConcreteRepository
{
    public ConcreteRepository(IUnitOfWork unitOfWork)
        : base(unitOfWork)
    {
    }
}

The only thing I would need to do when I switch between NHibernate or Entity Framework now is to change the using statement and the project references to point to the proper assembly containing the specific classes and interfaces!

using Storminajar.Framework.Data.NHibernate;

using Storminajar.Framework.Data.EntityFramework;

Of course I would still need to make my application aware of which Unit of Work to use and I would have to implement that logic somewhere, but at least I won’t have to change my code of my repositories!