Storm in a Jar » Design Patterns

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.

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.

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!

Generic factory and repositories: Part 2 revisited

Rob Jones — Tue, 18 May 2010 14:13:11 +0000

This post is part of a series:
- Generic factory and repositories: Part 2 revisited
- Generic factory and repositories: Part 2
- Generic factory and repositories: Part 1
- WCSF, Repositories and Unit of Work?

In Part 2 I discussed my implementation for a SimpleRepositoryFactory. I said that I wasn’t quite happy with the implementation of the factory class, as I would have to adjust my Create() method every time I would add a new repository to the project. At first I was looking for a solution that would let me pass a typeof() into the generic parameter of the InternalRepositoryFactory. For example, I wanted to do something like:

InternalRepositoryFactory.Create();

Of course this doesn’t work. Generics need to be resolved at compile time and therefore it’s impossible to create the code I wanted. Or is it?

There is one way of dynamically inserting types into a generic class and/ or method during runtime: reflection! I might be a bit of a nerd, but I love working with reflection. It can do everything! This doesn’t mean I use it inappropriately, I just happen to like the challenge of diving into completely unreadable code and making stuff work!

I managed to adjust my SimpleRepositoryFactory in such a way that I would never need to touch the Create() method again. Even if I add new repositories to the project at a later stage!

public static class SimpleRepositoryFactory
{
    private static Dictionary repositoryTypes =
        new Dictionary()

    /// 
    /// Creates repository object based on its interface
    /// 
    /// 
    /// 
    /// 
    public static T Create(params object[] args)
    {
        if (repositoryTypes.ContainsKey(typeof(T)))
        {
            // Create InternalRepositoryFactory.
            Type internalFactory =
                typeof(InternalRepositoryFactory<,>);
            internalFactory = internalFactory.MakeGenericType(
                typeof(T), repositoryTypes[typeof(T)]);

            // Get the Create() method from the
            // InternalRepositoryFactory.
            MethodInfo method = internalFactory.GetMethod(
                "Create", BindingFlags.Static |
                BindingFlags.NonPublic);

            // Invoke the Create() method and return the result.
            // For some reason I need to wrap 'args' into a new
            // object[]?
            return (T)method.Invoke(
                internalFactory, new object[] {args});
        }
        else
        {
            throw new Exception("Type: " + typeof(T)
                + " does not exist in dictionary. Register"
                + " the type mappings first by using the"
                + " RegisterTypeMapping method.");
        }
    }

    /// 
    /// Registers the repository types, marking them as
    /// available to use with the RepositoryFactory.
    /// 
    /// Interface type of object.
    /// Concrete type of object.
    public static void RegisterTypeMapping()
    {
        // Only add the type mapping if it doesn't exist.
        if (!typeMapping.ContainsKey(typeof(I)))
        {               �
            typeMapping.Add(typeof(I), typeof(C));
        }
    }
}

There are multiple downsides to this code.

Even though I don’t have to touch the Create() method any more, I have to maintain the internal dictionary with definitions. I have moved the problem to a different area in my code. However, the positive side of this is that I can’t break the implementation by accident. If I need to be able to instantiate a new repository, I will add a new definition to the dictionary, using the RegisterTypeMapping() method.

Another downside is that I’ve made the code a lot more complex! This does not improve readability or maintainability at all! Imagine a colleague, unschooled in the ways of reflection, needs to make changes to this code while I am on holidays… the poor bastard would have a very hard time trying to figure it all out!

I can imagine the performance takes a hit as well. I have no clue how much, as I haven’t bothered to measure. However, I think we can all agree that using reflection to resolve types and invoke methods is a bit more costly than simply invoking a method with generics.

I have no idea whether I should use this code or not. I’ve wrote it, I’ve seen it works and I enjoyed the challenge of figuring it out, but all the potential downsides make me scratch my head whether or not I should revert the code back to the way it was. I did write this post in case you, as reader, might really need to do something similar. Therefore I will let you make up your own mind and I won’t tell you what’s right or wrong. Just remember to sit down and think it over again when you suspect you need to resolve generics dynamically at runtime!

Lastly, I’d like to point out that I’ve moved far away from my original intent of developing a factory to create repositories, instead it has become a very generic class that can instantiate any sort of object as long as it implements an interface that can be returned. I’m not even sure if it can actually be classified as a factory pattern any more. SimpleRepositoryFactory seems a very inadequate name as it does not describe the actual implementation!

Generic factory with repositories: Part 2

Rob Jones — Tue, 18 May 2010 08:55:20 +0000

Yesterday I posted my musings on using the factory pattern to instantiate my repositories without needing to have a reference to the actual repository class, but only the interface. This morning I made some progress and I have actually managed to create some working code. Some of the code, especially the SimpleRepositoryFactory, can do with a little refinement. However, the basic principle seems to be working and that is all that matters at the moment.

The Repositories

Let’s start with the beginning and have a look at how I defined my repository classes and interfaces.

public interface IRepository where T : class
{
    IQueryable AsQueryable();
    IEnumerable GetAll(string[] includes = null);
    IEnumerable GetMany(Expression> where,
        string[] includes = null);
    T GetSingle(Expression> where,
        string[] includes = null);
    T GetFirst(Expression> where,
        string[] includes = null);
    void Delete(T entity);
    void Add(T entity);
}

public abstract class Repository : IRepository
    where T : class
{
    private IUnitOfWork unitOfWork;

    public Repository(IUnitOfWork unitOfWork)
    {
        this.unitOfWork = unitOfWork;
    }

    #region IRepository members
    // For the sake of simplicity, I'll leave the implementation
    // of the IRepository interface away. I might put up a source
    // code zip package later!
    #endregion
}

Now that I have the crude basics for a repository, it’s time to put them to work.

The following code demonstrates how to declare a repository that uses the IRepository interface and the abstract Repository base class. Because the IUserRepository interface implements the IRepository interface, I will be able to call all methods declared in IRepository by talking to my IUserRepository. This is pretty neat, since I won’t ever need to know anything about the concrete implementations when I start implementing the code in my (web) application.

public interface IUserRepository : IRepository
{
}

public class UserRepository : Repository, IUserRepository
{
    public UserService(IUnitOfWork unitOfWork)
        : base(unitOfWork)
    {
    }
}

The generic factory

Now that I’ve shown you the basics of my repository, I will show you the implementation of my SimpleRepositoryFactory. Mind you, it’s nothing special and it’s exactly what the name suggests; simple.

public static class SimpleRepositoryFactory
{
    public static T Create(params object[] args)
    {
        if (typeof(T) == typeof(IUserService))
        {
            // Excuse me for the code mark-up here!
            return (T)InternalRepositoryFactory.Create(args);
        }
        else
        {
            return default(T);
        }
    }
}

The downside of using this approach is that I will have to edit the SimpleRepositoryFactory with every new repository class I might add. A little inconvenient, but for now it suits me fine as I will only need to add it in the Create() method of the factory by using another else-if statement. You might notice that this class calls InternalRepositoryFactory to actually instantiate the object.

The InternalRepositoryFactory is actually a very generic object factory. It will be able to create any object, as long as the object implements the specified interface.

internal static class InternalRepositoryFactory where C : I
{
    internal static I Create(params object[] args)
    {
        return (I)Activator.CreateInstance(typeof(C), args);
    }
}

Using the factory!

Now that I’ve got all the pieces of the puzzle, it’s time to start putting it all together. Notice how I will still be able to use my repositories and unit of work as I described here! Not only that, but I’m also using interfaces instead of instantiating concrete implementations of my repositories!

using (TransactionScope ts = new TransactionScope())
{
    using (IUnitOfWork uof = new ConcreteUnitOfWork())
    {
        // Get reference to UserRepository.
        IUserRepository ur =
            SimpleRepositoryFactory.Create(uof);

        // Get all users.
        List users = ur.GetAll().ToList();

        // You can create more repositories here and
        // do additional work using this unit of work
        // and transaction scope!

        // We're done!
        uof.Commit();
        ts.Complete();
    }
}

Conclusion

I’m not really sure if this approach is correct, but for now I have solved the problem that I posted about yesterday in Part 1. This solution will allow me to create different modules and have interaction between them by only using their interfaces without needing to instantiate concrete implementations that would make my code too tightly coupled. I’m not quite happy with the implementation of SimpleRepositoryFactory and I will continue to look for a more elegant solution.

Generic factory with repositories: Part 1

Rob Jones — Mon, 17 May 2010 18:06:36 +0000

My previous post was about using WCSF in combination with repositories and a unit of work. I didn’t have any clear answers then and I don’t have any clear answers now. It doesn’t matter any more though, since I decided to drop WCSF entirely and pursue my own implementation of a modular web application, based on MVP, where I can still use my repositories as I would like.

The reasons why I’m doing this don’t matter. It has some very solid grounds, but I won’t discuss them as it’s not in the scope of this post.

Let’s take a look at the situation I’m faced with for a new proof of concept project:

I need to be able to make a simple modular web application. Users would need to be able to enter meeting-reports as well as enter activities. However, some issues in the meeting will have led to activities needing to be completed. So it should also be possible to create activities when entering a meeting-report.

In this case I will have two modules in my system: MeetingReports and Activities. The MeetingReports module will need to use the ActivitiesRepository within the Activities module to be able to create activities.

I won’t go into details, but WCSF had this nicely covered by working with dependency injection and interface libraries. That’s a practice from WCSF that I would like to adapt. However, I can’t simply make a reference from MeetingReports to the activties interfaces. I will have to instantiate a concrete class at some point!

What if I would be able to make a generic factory that instantiates repositories for me and returns their interface? I would be able to use the repositories without needing to know anything about their implementations.

I don’t have any concrete code yet (what a surprise!), but I would imagine something similar to this might be very possible:

using (IUnitOfWork uof = new UnitOfWork)
{
    IMeetingReportRepository irr =
        RepositoryFactory.Create(uof);
    irr.Insert(meetingReport);

    IActionRepository iar =
        RepositoryFactory.Create(uof);

    // Save all activities.
    foreach (Activity a in meetingReport.Activities)
    {
        iar.Insert(a);
    }

    uof.Commit();
}

The factory class would know how to instantiate ActionRepository based on the fact that its create method has been called with an IActionRepository generic! This way the factory will do the concrete instantiation while the activities module will only see, and use, the interface!

Hopefully I will be able to show some working C#-code soon, so stay tuned (yes, again)…

WCSF, Repositories and Unit of Work?

Rob Jones — Tue, 11 May 2010 13:44:04 +0000

In my research for designing and implementing modular web applications, I’ve come across the Web Client Software Factory. I’ve already briefly touched this subject in a previous post. It heavily uses the Composite Web Application Block to implement a Model-View-Presenter approach for a web application. It allows developers to compose applications from different pieces of software (modules). One of the advantages of this approach is that these modules can be developed independently from each other by different teams of developers. Another advantage is that the entire web application consists of separate blocks of software that are loosely coupled. I’m sure you’ve heard that term used by someone before!

As I was evaluating WCSF I stumbled on an interesting question. A question which I have no answer to yet.

In the past I’ve successfully used Microsoft’s Entity Framework. It’s relatively straight forward to implement a Repository Pattern in combination with a Unit of Work. If you have no idea what I’m talking about, here is a nice example. Admittedly, it’s an implementation for NHibernate, but it can just as easily be implemented for EF. The beauty of this approach was that I could use a single ObjectContext and pass it on to multiple repositories. This allowed me to use different repository classes in the same TransactionScope.

Here’s a quick example to show what I mean:

using (TransactionScope ts = new TransactionScope())
{
    // Create unit of work.
    using (IUnitOfWork uof = new ConcreteUnitOfWork())
    {
        // Create repositories and pass unit of work.
        OrderRepository or = new OrderRepository(uof);
        CustomerRepository cr = new CustomerRepository(uof);

        // place order in the system.
        or.Insert(customer.Order);

        // update order history for the customer.
        cr.UpdateHistory(customer);

        // So far, so good! Save all the changes.
        uof.Commit();
        ts.Complete();
    }
}

This is a simple piece of code that shows a single transaction over multiple repositories. In this scenario I had complete control over creating an ObjectContext and releasing its resources (IUnitOfWork implements IDisposable which will clean up any resources). In this way I had full control over creating a fresh ObjectContext for each new business transaction and automatically disposing it when the code finishes executing the using-statement.

I wanted to have the same functionality with implementing WCSF. I’ve had a good long look at the sample OrderManagementRI implementation that comes with the WCSF sources. It’s an excellent example of how they implement repositories and use them as a service within a module. I’ve been able to recreate a similar scenario in my proof of concept application, but I found I no longer have any control on my IUnitOfWork since it is created and passed on to the repositories by using Dependency Injection.

I’ve been searching on the web for a solution, but so far I’ve not found it yet. I’d like to have the same functionality with my IUnitOfWork. I want to be able to create a new one to pass along to multiple repositories in a transaction, while still having the benefits of the modular service approach of WCSF. I have a feeling that I should be able to create something much more to my liking if only I understood more of both WCSF and Dependency Injection principles.

To be continued (again)…

Creating modular web applications

Rob Jones — Wed, 28 Apr 2010 10:17:15 +0000

Before you read on, if you stumbled on this link through a search engine I will not waste your time and say I won’t be telling you how to do it. Instead, I’m going to share my experience of researching this topic.

It all sounds so beautiful. The idea of creating a web application that is built by separate blocks of functionality that can be developed independently of each other, but are still smart enough to work together if necessary. I started out thinking that I wouldn’t be the first person to have this brilliant idea and that there would be plenty helpful topics to help me get my journey underway. I had absolutely no idea what I would get myself into! Believe me when I tell you that implementing this idea is easier said then done!

I’ve always considered myself an able software developer who likes to dabble with getting projects started and setting up their architectures. Who have I been kidding?! Shortly after starting my research it was evident that there’s no out-of-the-box solution readily available. There are in fact a lot of ways to achieve this goal.

In the past week(s) I have found that my knowledge did not carry me as far as I had expected it would. I’ve read various books on Design Patterns and supposed that I understood most of the concepts I had read about. After having read many articles, I’ve been beaten to death with a lot of complicated words. Separation of Concerns, Model View Controller, Model View Presenter (and all their various little brothers and sisters), Inversion of Control, Dependency Injection and I could continue adding terms this list! Eventually I found myself reading up on Workflow Foundation and Service Oriented Architectures as well.

It made me scratch my head. I’ve read about most and heard about others, but found that my knowledge doesn’t extend past that. I’m hazy on the actual implementation of all these patterns and there’s such an abundance of literature to read that I feel I’m getting deviated from my original goal. However, getting to that goal will require me to dust off some of my knowledge and start polishing it to a shine again… It’s a nasty little circle that I will have to break out of. In any case it’s proving the point of what I was trying to convey to my old employer, it’s important to know about design patterns and their implementations!

At the moment I’m edging towards the possibility of a proof of concept implementation using the Model View Presenter design pattern in combination with ASP.NET WebForms. As far as I can tell right now this is going to be the most flexible way and reap the best of both worlds: seperation of concerns with an MVP approach (probably aided by Composite Web Application Block), combined with the strength and productivity WebForms can bring in terms of controls, such as Telerik.

Perhaps I will follow up on this topic later when I have a clearer vision on which approach to take and why.