Introduction

Garbage Collection sure is great, isn’t it? We don’t have to keep track of all the memory we’ve allocated and we don’t need to release that memory when it’s no longer needed. Because that is after all what the Garbage Collector does for us, without us having to worry about it. This is actually a widespread misconception among many .NET developers. It’s true that Garbage Collection makes memory management a lot easier, but we simply can’t rely on it all the time. There are most certainly some things you must always keep in mind when it comes to memory management in .NET.

Different Kinds Of Resources, Different Consequences

In most pieces of code, you use variables. A lot of these variables are references to objects. When your variables go out of scope, they no longer exist. When those variables are references to objects, only your reference is gone and the actual object that was referred to is still in memory somewhere. The Garbage Collector (GC) makes sure that orphaned objects (objects that no longer have a usable reference to them) are removed from memory. This is an automatic process within the .NET runtime. Essentially, the GC periodically performs some checks on objects and if it comes to the conclusion that certain objects are no longer needed, it will remove them from memory. This is a gross oversimplification of how it really works, but that is what it comes down to and that is also how most people think about the GC.

The GC in .NET is very smart and will almost always do a better job of memory management than you will. But there is one huge downside to it: the GC runs periodically and you have no deterministic way of knowing when it will run. Sure, you can instruct the GC to perform a collection but in most cases that will actually have a negative impact on the memory management of your application. I won’t go into the details here, but i will provide a follow-up post on this later on. For now, keep in mind that forcing a garbage collection to occur is really something you should avoid.

So is it really a problem that you don’t know for certain when the GC will run? It depends on which kind of objects that need to be removed from memory. There are basically 2 kinds: managed and unmanaged resources. Managed resources are typical .NET types. Unmanaged resources (also referred to as Native Resources) are things that fall outside of the scope of the .NET managed environment. These are usually things that are available within the Operating System, or that are available through lower-level development API’s (such as the Win32 API for instance). Unmanaged resources can’t be cleaned up automatically by the .NET runtime, so if you use them directly, you are responsible for cleaning up after you’ve used them. Luckily, a lot of managed types are available that take care of the dirty details for you. For instance, if you need to use a file in .NET, you’ll typically use a FileStream instance or something else that easily makes the content of the file available to you, or that easily allows you to write content to a file. The FileStream is a managed type, but it uses unmanaged resources to implement the functionality it offers.

Now think about this: you are using a managed type, so you shouldn’t need to perform any cleanup, right? However, if that managed type uses unmanaged resources then they still need to be cleaned up. And those unmanaged resources should be cleaned up as soon as possible because they can be quite expensive. These types usually offer a way to clean up the unmanaged resources they use in a deterministic manner. They usually implement the IDisposable interface, which exposes a Dispose method. When you call the Dispose method, the unmanaged resources are cleaned up right then and there and then there’s no need to wait for the garbage collector, which again, could be quite expensive when you (either directly or indirectly) have a bunch of unmanaged resources in memory that are waiting to be cleaned up.

Disposable Managed Resources

I call types that implement the IDisposable interface Disposable Managed Resources. They are indeed managed types and thus they are guaranteed to be cleaned up when the GC comes around and notices that instances of these types are no longer needed. However, if you merely trust on the GC to clean up instances of these types you are taking quite a risk. Any expensive resource it may hold might be cleaned up a lot later than it could have been. Which can be very inefficient, and thus, quite costly.

If a type implements the IDisposable interface, it usually has a good reason for doing so (there are of course exceptions to the rule). It is essentially a way of telling consumers of the type that it offers a deterministic way of cleaning up the resources it consumes and i believe you should take advantage of that. If you don’t, you may end up with inefficient memory management, and that’s when people start complaining that Garbage Collection is ‘evil’ or that it ’sucks’. In most cases, people who feel that way simply don’t know how to use it properly. The IDisposable interface and the Dispose Pattern (which we’ll get to in a minute) allow you to avoid most of the issues that are generally attributed to the Garbage Collection in general.

So how do we deal with this? First of all, if a type uses unmanaged resources, it should implement the IDisposable interface using the Dispose Pattern. Secondly, if any of your types use other types that implement IDisposable, it is your responsibility to make sure these types are properly disposed of. You either dispose them when you no longer need them, or you must implement IDisposable and the Dispose Pattern yourself to make sure the Disposable Managed Resources you depend on are indeed properly disposed of. If you need to implement IDisposable, your type effectively becomes a Disposable Managed Resource itself. A lot of people think that this isn’t necessary, but by not doing so they are breaking the contract that the IDisposable interface implies. If a type implements IDisposable then either that type or any other type it may use probably uses unmanaged resources somewhere and you want to see these get cleaned up as soon as possible. Because of that, i believe it’s best to implement IDisposable yourself if you’re holding any reference to a type that also implements it.

The Dispose Pattern

Implementing the IDisposable interface can be as easy as merely providing a public Dispose method where you perform your cleanup. That’s really not a good way of doing it though, as it could lead to a bunch of other problems which might actually make the situation worse. The best way to implement the IDisposable interface is to implement the Dispose Pattern, which looks like this:

    public class MyDisposableClass : IDisposable

    {

        private bool disposed = false;

 

        public void Dispose()

        {

            Dispose(true);

            // prevent this object from being placed in the finalization queue if some

            // derived class provides a finalizer

            GC.SuppressFinalize(this);

        }

 

        protected virtual void Dispose(bool disposing)

        {

            if (!disposed)

            {

                if (disposing)

                {

                    // dispose all Disposable Managed Resources here

                }

 

                // dispose all Unmanaged Resources here

 

                // set disposed to true to prevent the code above from being

                // executed a second time

                disposed = true;

            }

        }

    }

If you don’t need a finalizer it’s best not to provide one (we’ll discuss finalizers later on). If you do need one, you would implement it like this:

        public ~MyDisposableClass()

        {

            Dispose(false);

        }

So what’s so good about the Dispose pattern? Well, we make a clear distinction between what should happen when the object is disposed through the Dispose method, or when it’s being cleaned up by the finalizer. When the clean up occurs through a call to Dispose, it calls the protected virtual Dispose method with the disposing parameter set to true. When this parameter is true, you should call the Dispose method of each Disposable Managed Resource you’re holding a reference to. Outside of the if-statement, you should clean up each unmanaged resource you may be holding.

If your class (or a derived class) implements a finalizer method, it should call the Dispose method with the disposing parameter set to false. The reason for this is that the order in which objects are finalized is not specified. If you’re not careful, you could accidentally call the Dispose method of a Disposable Managed Resource which may have already been finalized as well. This would cause an exception and a finalizer method should never ever throw an exception because that could keep other objects from being finalized.

If you can, try to put this pattern into a reusable base class and make your Disposable Managed Resource holding types inherit from this. An example of this approach can be found here.

Using Disposable Managed Resources

In a lot of cases, you will use a Disposable Managed Resource within the scope of one method. In that case, you certainly don’t need to implement IDisposable. There are two things to keep in mind though. If you receive the Disposable Managed Resource as a method parameter, you are not responsible for disposing it! Somebody else created it, let them take care of the disposal. Things will most likely go wrong if you dispose objects that have been giving to you by somebody else. So in this case, you would just use the object and not worry about it any further:

        public void DoSomethingInteresting(MyDisposableClass disposableResource)

        {

            // … some code could go here

            disposableResource.DoWhateverItIsThatMakesYouSoSpecial();

            // … some code could go here

 

            // we reach the end of the method and we haven’t Disposed the

            // Disposable Managed Resource because it wasn’t our responsibility

        }

However, if you create the object yourself, then you are responsible for getting rid of it properly. In that case, use a using block to make sure the object is disposed of even in case of unhandled exceptions:

        public void DoSomethingInteresting()

        {

            // … some code could go here

            using (var myDisposableResource = new MyDisposableClass())

            {

                myDisposableResource.DoWhateverItIsThatMakesYouSoSpecial();

            }

            // … some code could go here

 

            // we reach the end of the method and we properly Disposed the

            // Disposable Managed Resource because it was our responsibility

        }

In case you don’t know, the using-block guarantees that the Dispose method will be called when we leave the scope of the block. It can get pretty tricky sometimes if you’re passing the Disposable Managed Resources to other objects that will hold a reference to them which will remain in use after you’ve left the using block. In this scenario, it’s possible that the object you’ve passed the Disposable Managed Resource to will try to invoke methods on the disposed instance. Also a situation you most certainly want to avoid because it will either cause unexpected behavior or even unhandled exceptions. The unhandled exceptions are easy to figure out, but the unexpected behavior might be difficult to debug. The key in this scenario, is to figure out a way to not call Dispose on the resource until the other object is done with it. Sometimes it might be enough to put your using block on a slightly higher level, other times you’ll have to keep a reference to the resource yourself, which effectively means you’ve now become an owner of the Disposable Managed Resource.

Owning Disposable Managed Resources

If you need to hold a reference to a Disposable Managed Resource, you are either the owner of the object or at least someone who owns a stake in the lifetime of the object. If you are the owner, and you do not pass the Disposable Managed Resource to any other object then the solution is easy: implement IDisposable. If you do pass the Disposable Managed Resource to other objects, then it can get tricky. Will they only use it to perform some action or will they hold a reference to it? If they hold a reference to it, it means that they too have a stake in the lifetime of the resource. Depending on the implementation of the other types, they may or may not call the Dispose method of the instance you created. Which could cause unexpected behavior or exceptions in your code. Make sure you are prepared for that if you’re passing these objects around. But you should definitely dispose of them in your own Dispose method.

If you didn’t create the Disposable Managed Resource, but you do need to hold a reference to it, then you’ve got some questions to answer. Does the type which provided you with the instance expect you to be solely responsible for the lifetime of the object? In case of factory classes or factory methods, the answer is usually ‘yes’. If you’ve been given the instance by something that will probably make use of that same instance, i think it’s better not to dispose it. Some people will probably disagree, but i don’t think it’s my responsibility to dispose objects that i didn’t create, unless the instance was given to me by a factory class or a factory method. I would expect that the real owner of the resource would dispose of it. Still, it’s a difficult call to make.

Finalizers

Finally, i’d like to add a few words about Finalizers in .NET. A finalizer is similar to a destructor in C++, in that it is the code that is run when your object is being removed from memory. The big difference is that you never know for sure when it will be run, which is why the IDisposable interface and the Dispose pattern was created. There are a lot of misconceptions going around about finalizers, so keep the following comments in mind.

First of all, finalizers only make sense when you have direct references to unmanaged resources. If you have unmanaged resources, implement IDisposable and provide a finalizer that calls the Dispose overload with the disposing parameter set to false. This should really be the only code inside your finalizer method.

Finalizers also come with a performance penalty. When finalizable objects are created, pointers to these objects are added to the finalization queue of the GC. These finalizable objects are collected less frequently because the GC performs finalizations through its finalization queue. This finalization process is not executed as frequently as regular garbage collections because it’s quite costly. So not only are finalizable objects cleaned up less frequently, it takes more processing power to do so. So if you have a lot of finalizable instances, your code’s performance can easily be impacted because of this.

Conclusion

I hope i made it clear that there is a lot more to automatic memory management in .NET than simply relying on the GC to take care of all of the details for you. There is a lot more stuff that i didn’t cover in this post (it’s long enough already) but most .NET developers will probably get by pretty well with the advice given in this post. It’s not an easy subject to explain so i hope everything was clear

Introduction

When you’re trying to design a service layer API, there are two things you always need to be very careful of. The first is making sure the API isn’t chatty. A service layer is usually deployed on another physical machine than the client layer, so you want clients to be able to do everything they need to do with a minimum of roundtrips, because those are after all rather expensive. The second thing you want to avoid is the implicit coupling between the client of the service and the service itself. In your quest to avoid the chatty interface, you might start grouping several service operations together in more coarse-grained operations to avoid the chatty communication that might otherwise occur. This can be good from a performance point of view, but it usually introduces a certain implicit coupling between the service and the client, because a specific grouping of operations might be beneficial to one client, but might be completely inappropriate to another type of client of the service.

I really had difficulties coming up with an approach that offered nice coarse-grained service interfaces while at the same time making sure the interfaces weren’t too ‘driven’ by a client’s specific requirements. So i basically wanted a way to keep my service operations as specific as they could be (very fine-grained), while avoiding the pitfall of chatty communication by batching calls to the service layer together whenever it makes sense from the client’s point of view. I eventually ended up with an approach that i’ve already documented here and here. Read those posts first before continuing with this post because the rest of this post builds upon the content of the previous posts.

The idea is to basically consider each service operation as a request which can have a response. For each request that you define, you need to provide a handler which does whatever it needs to do to handle the request and returns a response, or an empty response if no response is needed for a specific request. You then only need one service method which receives incoming requests, delegates them to the proper handlers, and returns each response in the order of the incoming requests. On a side note: this approach probably doesn’t sit well with many SOA people, but then again, i couldn’t care less about SOA. I just want good software no matter what acronym i can use to describe it.

Anyway, i like this approach so much that i wanted to make it available to whoever is interested in it. You can find it in my open source library which you can find here. I won’t go into the details of the implementation, because those have mostly been covered already in my previous posts on this subject. The rest of this post focuses solely on how you can use this approach in your projects.

Defining Requests and Responses

The following two base classes need to be used to define request and response types:

namespace Brion.Library.Common.Messaging

{

    [Serializable]

    public abstract class Request {}

 

    [Serializable]

    public abstract class Response { }

 

}

Suppose you have a service operation that retrieves a list of products based on some parameters the user could provide in the UI. You would define the request like this:

    [Serializable]

    public class GetProductOverviewsRequest : Request

    {

        public string NamePattern { get; set; }

        public int? CategoryId { get; set; }

        public int? SupplierId { get; set; }

    }

And the response would look like this:

    [Serializable]

    public class GetProductOverviewsResponse : Response

    {

        public ProductOverviewDTO[] Products { get; set; }

    }

Keep in mind that these types always need to be marked with the Serializable attribute and that these types need to be in an assembly that you can share between both the client and the service.

Handling Requests

Incoming requests are handled by a class which implements the IRequestProcessor interface:

namespace Brion.Library.Common.Messaging

{

    public interface IRequestProcessor : IDisposable

    {

        Response[] Process(params Request[] requests);

    }

}

For each request that is received, the request processor will create a request handler which must be of the type IRequestHandler<TRequest> where TRequest is the type of the request instance. The request object is then passed along to the handler’s Handle method, which will return a proper Response object.

The simplest way to create a request handler is to inherit from the RequestHandler<TRequest> class, like this:

    public class GetProductOverviewsHandler :

        Brion.Library.ServerSide.Messaging.RequestHandler<GetProductOverviewsRequest>

    {

        public IProductRepository ProductRepository { get; private set; }

 

        public GetProductOverviewsHandler(IProductRepository productRepository)

        {

            ProductRepository = productRepository;

        }

 

        public override Response Handle(GetProductOverviewsRequest request)

        {

            var products = ProductRepository.FindAll(request.NamePattern, request.SupplierId,

                request.CategoryId);

 

            return new GetProductOverviewsResponse { Products = products.ToOverviewDTOs() };

        }

    }

The request processor uses the Castle Windsor Inversion Of Control container to resolve and create the instances of the request handler types. This allows you to use dependency injection for your request handlers. In the example posted above, you can see that the constructor of the handler takes an IProductRepository instance. Because the Windsor container also knows about the IProductRepository component in my application, it can correctly instantiate the GetProductOverviewsHandler instance with a valid IProductRepository instance. Keep in mind that this is optional though. You don’t have to use dependency injection for your request handlers if you don’t want to.

If you do want to use it, your application will have to use the same Windsor container instance as this library does. To make this possible, the library contains the following class:

namespace Brion.Library.Common

{

    public static class IoC

    {

        private static IWindsorContainer container = new WindsorContainer();

 

        /// <summary>

        /// Gets/Sets the current Windsor container. Applications can either use

        /// the reference to the container that this property provides, or they

        /// can set their own reference through the setter.

        /// </summary>

        public static IWindsorContainer Container { get; set; }

    }

}

By default, an empty container is created which you can access (and thus, configure) through the IoC.Container property. Or if you want the library to use your own Windsor container instance you can simply set the instance and then the library will use your container. For the moment, it is not possible to use another container (like StructureMap or Unity) yet, but that possibility might be added if people want it, or if someone submits a patch

Obviously, you need to register your request handlers somewhere in your application code, preferably before you start hosting the service layer. You can do that like this:

            Brion.Library.ServerSide.ComponentRegistration

                .RegisterRequestHandlersFrom(Assembly.GetExecutingAssembly());

That basically registers each valid request handler (each type that inherits from the RequestHandler class provided by the library) that is present in the given assembly. You can also very easily provide your own custom base request handler, in case you want to provide some extra stuff. You’d simply need to inherit from the library’s RequestHandler class, add whatever it is you need, and let your request handlers inherit from your new class instead of directly inheriting from the library’s RequestHandler.

Hosting The Service Layer

There are a lot of options for hosting the service layer. Most people will probably host it as a WCF service so we’ll cover that scenario here. The service contract looks like this:

namespace Brion.Library.Common.WCF

{

    [ServiceContract]

    public interface IWcfRequestProcessor

    {

        [OperationContract]

        [ServiceKnownType("GetKnownTypes", typeof(KnownTypeProvider))]

        Response[] Process(params Request[] requests);

    }

}

This is practically identical to the IRequestProcessor interface shown earlier in the article. The difference is that IRequestProcessor uses no WCF attributes. The actual implementation of IRequestProcessor is completely decoupled from WCF as well so you can use this approach without having to use WCF if you want to. The implementation of the IWcfRequestProcessor simply forwards each call to the real request processor.

Notice the usage of the KnownTypeProvider class. This makes sure that each of your Request or Response derived types will be properly recognized as a KnownType. All you have to do is register them, like this:

            KnownTypeProvider.RegisterDerivedTypesOf<Request>(sharedAssembly);

            KnownTypeProvider.RegisterDerivedTypesOf<Response>(sharedAssembly);

This registers each Request or Response derived type from the sharedAssembly reference (which is a reference to the shared assembly containing the request and response types) with the KnownTypeProvider. You need to do this before you start hosting the service. It’s best to combine this task with the registration of your request handlers.

The actual hosting of the service is typical WCF and is entirely up to you. Here’s a simple example of self-hosting the service in a console app:

    <services>

      <service name=“Brion.Library.ServerSide.WCF.WcfRequestProcessor“ behaviorConfiguration=“MyBehavior“>

        <endpoint contract=“Brion.Library.Common.WCF.IWcfRequestProcessor“ binding=“netNamedPipeBinding“

              bindingConfiguration=“MyNamedPipeBinding“ address=“net.pipe://localhost/RequestProcessor“/>

      </service>

    </services>

            using (var host = new ServiceHost(typeof(WcfRequestProcessor)))

            {

                host.Open();

 

                Console.WriteLine(“press ENTER to quit”);

                Console.ReadLine();

            }

You’ll most likely prefer an alternative way of hosting the service, but again, that is entirely up to you and is typical WCF stuff. All you need to know is that the service contract is the Brion.Library.Common.WCF.IWcfRequestProcessor interface, and the actual implementation of the service is the Brion.Library.ServerSide.WCF.WcfRequestProcessor class.

Communicating With The Service Layer

In your client layer, you can choose between using a direct proxy type for the IWcfRequestProcessor service, or you can use the Dispatcher class. The Dispatcher class is somewhat of a wrapper around the direct proxy to make it easier to use and to get a nicer syntax. The Dispatcher class implements the IDispatcher interface:

namespace Brion.Library.ClientSide.Messaging

{

    public interface IDispatcher : IDisposable

    {

        IEnumerable<Request> Requests { get; }

        IEnumerable<Response> Responses { get; }

 

        void Add(Request request);

        void Add(params Request[] requestsToAdd);

        void Add(string key, Request request);

        TResponse Get<TResponse>() where TResponse : Response;

        TResponse Get<TResponse>(string key) where TResponse : Response;

        TResponse Get<TResponse>(Request request) where TResponse : Response;

        void Clear();

    }

}

There are 3 implementations of this interface. The first is the Dispatcher class itself, which has a dependency on an IRequestProcessor instance. The second is the WcfDispatcher class which inherits from the Dispatcher class and will supply its base class with a RequestProcessorProxy instance to satisfy the IRequestProcessor dependency. The third implementation is the DispatcherStub class, which is only useful for your tests. If you want to use dependency injection through the container, you can register the correct components at client start-up time like this:

            Brion.Library.ClientSide.ComponentRegistration.RegisterDispatcherForWcfUsage();

The container will then have the correct configuration to provide you with IDispatcher instances that will correctly use the RequestProcessorProxy underneath. If you don’t want to use the container client-side, you can simply instantiate instances of the WcfDispatcher class.

So, how do you use the dispatcher? It’s pretty easy really. Suppose you want to dispatch two requests to the service, you could do so like this:

                dispatcher.Add(new GetProductCategoriesRequest(), new GetSuppliersRequest());

                View.ProductCategories = dispatcher.Get<GetProductCategoriesResponse>().ProductCategories;

                View.Suppliers = dispatcher.Get<GetSuppliersResponse>().Suppliers;

The requests won’t be dispatched to the service until you actually call one of the Get method overloads for the first time. So you can add as much requests as you like, they won’t be dispatched until you try to retrieve a response. And when those requests are dispatched, it is done in only one roundtrip.

If you just want to dispatch a single request, you could do so like this:

            var request = new GetProductOverviewsRequest

                { NamePattern = name, CategoryId = productCategoryId, SupplierId = supplierId };

            var response = dispatcher.Get<GetProductOverviewsResponse>(request);

            View.Products = response.Products;

Keep in mind that you do need to define the service endpoint in your client-side application’s configuration file. You also need to register the KnownTypes client-side before you start using the Dispatcher or the service proxy in the manner discussed earlier.

Stubbing The Service Layer During Testing

If you write tests for your client-side code, you’ll be glad to hear that i’ve included a DispatcherStub class which makes it easy to prepare responses to return and to inspect requests that were sent from the code you’re testing. The approach i outlined in this post doesn’t really lend itself to easy mocking, so the DispatcherStub class makes it all much easier.

First of all, make sure your client code always uses references of the IDispatcher type instead of directly using the Dispatcher or WcfDispatcher types. Then in your tests, inject DispatcherStub instances instead of real Dispatchers. The DispatcherStub class provides a few extra methods which you can use in your tests:

        [Test]

        public void RetrievesCategoriesAndSuppliersOnLoad()

        {

            var categoriesToReturn = new ProductCategoryDTO[0];

            var suppliersToReturn = new SupplierDTO[0];

 

            dispatcher.SetResponsesToReturn(

                new GetProductCategoriesResponse { ProductCategories = categoriesToReturn },

                new GetSuppliersResponse { Suppliers = suppliersToReturn });

 

            view.Expect(v => v.ProductCategories = categoriesToReturn);

            view.Expect(v => v.Suppliers = suppliersToReturn);

            view.Expect(v => v.DataBind());

 

            mocks.ReplayAll();

            CreateController().Load();

 

            view.VerifyAllExpectations();

            Assert.IsNotNull(dispatcher.GetRequest<GetProductCategoriesRequest>());

            Assert.IsNotNull(dispatcher.GetRequest<GetSuppliersRequest>());

        }

The SetResponsesToReturn and GetRequest methods make it much easier to stub the service layer than traditional mocking would.

Something you’ll often want to test is that requests have been sent with the correct parameters:

            var request = dispatcher.GetRequest<GetProductOverviewsRequest>();

            Assert.AreEqual(productPattern, request.NamePattern);

            Assert.AreEqual(categoryId, request.CategoryId);

            Assert.AreEqual(supplierId, request.SupplierId);

Time to wrap it up

Again, i really like this approach. Unfortunately i haven’t had the chance to use this in a real project yet, but based on my experiments i’m already very happy with it and am looking forward to use this in a real project. If you’d like to use this approach, download the library here, play around with it, try it out, try to break it, and let me know what needs to be fixed/changed/added. Or send patches

I was working on my northwind sample application (which i’ll post about as soon as i get something that’s worth showing) and i was struggling to find a clean way to manage my NHibernate sessions. I wanted a way to create a session once you enter the service layer, and that session should be available transparently to the repository implementations without actually having to constantly pass it around. But i didn’t just want to store it somewhere and have all the classes that needed the current session get it directly from that place. Also, i didn’t want the current session to be available to everyone. Another important requirement was to have maximum flexibility for writing tests. I could just use Rhino-Commons’ implementations of the UnitOfWork and Repository patterns and be done with it, but where’s the fun in that? And since this application is mostly a learning experience i figured i should try to write this myself. After a bit of searching and experimenting, i finally came up with a way that i’m happy with (for now anyways). Let’s have a look.

To illustrate what i want, take a look at this made-up method in my service layer:

        public ProductCategoryDTO[] GetAllProductCategories()

        {

            using (ISession session = GetNewSession())

            {

                var repository = GetProductCategoryRepository();

                var categories = repository.GetAllProductCategories();

                return categories.ToDTOs();

            }

        }

This is just some example code, it doesn’t even work. But it’s kinda what i want… The thing is, i don’t want to deal directly with the ISession type in the service layer, but i do want the ProductCategoryRepository to use the ISession that is created within the context of this method call.

NHibernate’s ISession type is an implementation of the Unit Of Work pattern. I don’t want to use the ISession directly in my service layer because i want something that is a bit more high-level. Basically just something that would allow me to work within an NHibernate session, and provide me with the ability to flush changes to the database whenever i want to. And obviously, i want it to allow me to create a transaction as well. So i came up with the following unit of work interface:

    public interface IUnitOfWork : IDisposable

    {

        /// <summary>

        /// Flushes any changes that haven’t been executed yet

        /// </summary>

        void Flush();

 

        /// <summary>

        /// Creates an ITransaction instance with the ReadCommitted isolation level

        /// </summary>

        /// <returns></returns>

        ITransaction CreateTransaction();

 

        /// <summary>

        /// Creates an ITransaction instance with the given isolation level

        /// </summary>

        /// <param name=”isolationLevel”></param>

        /// <returns></returns>

        ITransaction CreateTransaction(IsolationLevel isolationLevel);

    }

This interface pretty much offers me anything i’m concerned with in my service layer. The real implementation would do a bit more though… It has to create an NHibernate session and make it available to the repositories in a clean way. Here’s the thing though… the repositories have a completely different lifetime than the NHibernate sessions. The NHibernate session has to be created when we enter a service method, and it has to be valid within the scope and context of the execution of that service method. The repositories however stay alive for the lifetime of the application so they can’t just hold a reference to an NHibernate session. Every time you call a method of a repository, it has to find out which session it should use, which is the session that is being used in the context of the current service method call. Now, we could always pass around the session but that really doesn’t look good and is cumbersome. So i basically need something that gives me access to the active nhibernate session:

    public interface IActiveSessionManager

    {

        /// <summary>

        /// Returns the active ISession for the current thread. Throws exception if there’s

        /// no active ISession instance

        /// </summary>

        /// <returns></returns>

        ISession GetActiveSession();

 

        /// <summary>

        /// Sets the active ISession for the current thread. Throws exception if there’s

        /// already an active ISession instance

        /// </summary>

        /// <param name=”session”></param>

        void SetActiveSession(ISession session);

 

        /// <summary>

        /// Clears the active ISession for the current thread.

        /// </summary>

        void ClearActiveSession();

    }

That gives me the ability to retrieve and set the active session on a per-thread basis. After all, a service method call will be handled by one thread, so setting the active session for that current thread is a convenient way to store the session.

Now i still need something that takes care of creating the NHibernate sessions:

    public interface ISessionFactory

    {

        /// <summary>

        /// Creates a new ISession instance

        /// </summary>

        /// <returns></returns>

        ISession Create();

    }

Ok, so what do we have so far? An interface to define the functionality that a UnitOfWork should offer at the service level. An interface to store/retrieve the active session on the current thread, and finally, an interface to actually create the NHibernate session. Let’s start looking at the real implementations. Here’s the code to the SessionFactory class:

    public class SessionFactory : ISessionFactory

    {

        private readonly NHibernate.ISessionFactory sessionFactory;

 

        public SessionFactory()

        {

            Configuration configuration = new Configuration()

                .Configure()

                .AddAssembly(“Northwind”);

 

            sessionFactory = configuration.BuildSessionFactory();

        }

 

        public ISession Create()

        {

            return sessionFactory.OpenSession();

        }

    }

Pretty straightforward… it initializes NHibernate and gives us the ability to ask for new sessions. So how are we going to make these sessions available to our repositories? Through the ActiveSessionManager class of course:

    public class ActiveSessionManager : IActiveSessionManager

    {

        [ThreadStatic]

        private static ISession current;

 

        public ISession GetActiveSession()

        {

            if (current == null)

            {

                throw new InvalidOperationException(“There is no active ISession instance for this thread”);

            }

 

            return current;

        }

 

        public void SetActiveSession(ISession session)

        {

            if (current != null)

            {

                throw new InvalidOperationException(“There is already an active ISession instance for this thread”);

            }

 

            current = session;

        }

 

        public void ClearActiveSession()

        {

            current = null;

        }

    }

It basically just stores the session in a ThreadStatic field, which means that each thread will have a different static reference for this field. So if we set the active session through the SetActiveSession method in thread X, and thread Y also sets an active session, the GetActiveSession method will return the correct session instances for each thread.

So now we have everything we need to create our UnitOfWork class:

    public class UnitOfWork : Disposable, IUnitOfWork

    {

        private readonly IActiveSessionManager activeSessionManager;

        private readonly ISession session;

 

        public UnitOfWork(ISessionFactory sessionFactory, IActiveSessionManager activeSessionManager)

        {

            this.activeSessionManager = activeSessionManager;

            session = sessionFactory.Create();

            activeSessionManager.SetActiveSession(session);

        }

 

        protected override void DisposeObjects()

        {

            if (session != null)

            {

                session.Close();

                session.Dispose();

            }

        }

 

        protected override void ClearReferences()

        {

            activeSessionManager.ClearActiveSession();

        }

 

        public void Flush()

        {

            session.Flush();

        }

 

        public ITransaction CreateTransaction()

        {

            return CreateTransaction(IsolationLevel.ReadCommitted);

        }

 

        public ITransaction CreateTransaction(IsolationLevel isolationLevel)

        {

            return session.BeginTransaction(isolationLevel);

        }

    }

When the UnitOfWork is created, it receives an ISessionFactory instance, and an IActiveSessionManager instance. It then creates a new session through the ISessionFactory and uses the IActiveSessionManager to make sure that session is the active session for the current thread. When the UnitOfWork is disposed, it closes and cleans up the session and it also uses the IActiveSessionManager to clear the active session for the current thread. Oh and it obviously also provides implementations for what it is we actually need in our service layer: flushing the changes whenever we want and creating transactions.

The ISessionFactory and IActiveSessionManager instances should stay alive as long as the application is alive. But as you could see in the implementations of those types, we didn’t write any code to deal with their lifetimes. I’m actually relying on my IoC container for that. In the class where my container is set up, you’ll find the following code:

        private static void RegisterUnitOfWorkComponents()

        {

            Register(Component.For<ISessionFactory>()

                .ImplementedBy<SessionFactory>().LifeStyle.Singleton);

            Register(Component.For<IActiveSessionManager>()

                .ImplementedBy<ActiveSessionManager>().LifeStyle.Singleton);

            Register(Component.For<IUnitOfWork>()

                .ImplementedBy<UnitOfWork>().LifeStyle.Transient);

        }

ISessionFactory and IActiveSessionManager are registered as singleton instances, so whenever these types are requested, the same instances will be returned. The IUnitOfWork type is registered with a transient lifetime, so whenever it is requested, the container will create a new UnitOfWork class and pass the ISessionFactory and IActiveSessionManager instances to the constructor.

Right, we’ve taken care of creating the session, associating it with the current thread and making it available in a nice and clean way. Now we actually have to make sure our repositories can use it. In the base repository implementation, you can find the following code:

        private readonly IActiveSessionManager activeSessionManager;

 

        public Repository(IActiveSessionManager activeSessionManager)

        {

            this.activeSessionManager = activeSessionManager;

        }

 

        protected ISession Session

        {

            get { return activeSessionManager.GetActiveSession(); }

        }

Whenever a repository needs a session, it just needs to use the protected Session property and it will get the session that is associated with the current thread.

So now we can rewrite our made-up service method from earlier to the following:

        public ProductCategoryDTO[] GetAllProductCategories()

        {

            using (Container.Resolve<IUnitOfWork>())

            {

                var repository = Container.Resolve<ProductCategoryRepository>();

                var categories = repository.GetAllProductCategories();

                return categories.ToDTOs();

            }

        }

We know that the NHibernate session will be created, and more importantly, that it is not just globally accessible to everyone. It can only be accessed when you have a reference to an IActiveSessionManager instance. We also don’t need to pass around the session all the time so our code is a bit more concise, showing only the intent of what we’re trying to do without distracting us with details that are not relevant to that intent. We also have a lot of flexibility to write tests… i can write tests for my repositories without having to create a UnitOfWork… i can simply pass a fake IActiveSessionManager to my repositories when i’m testing them and have it return the session that i’m using for my test. All in all, this approach offers me with a lot of advantages, without ugly disadvantages. Well, at this moment i don’t really see any disadvantages so if you do see some, please let me know

Everytime i need to implement the IDisposable interface i have to lookup the recommended way of doing so. That in itself is a bad sign, so i figured i might as well get rid of this by putting the implementation in a reusable base class, based on the officially recommended way:

    public abstract class Disposable : IDisposable

    {

        private bool disposed;

 

        public void Dispose()

        {

            Dispose(true);

            GC.SuppressFinalize(this);

        }

 

        protected void Dispose(bool disposing)

        {

            if (!disposed)

            {

                if (disposing)

                {

                    DisposeManagedResources();

                }

 

                DisposeUnmanagedResources();

                disposed = true;

            }

        }

 

        protected void ThrowExceptionIfDisposed()

        {

            if (disposed)

            {

                throw new ObjectDisposedException(GetType().FullName);

            }

        }

 

        protected abstract void DisposeManagedResources();

        protected virtual void DisposeUnmanagedResources() {}

    }

So now i can simply inherit from Disposable, and i just need to implement the two abstract methods. Here’s a made up example to illustrate this:

    public class MyExpensiveResource : Disposable

    {

        private FileStream fileStream;

        private MemoryStream memoryStream;

 

        public MyExpensiveResource(string path)

        {

            fileStream = new FileStream(path, FileMode.Open);

            memoryStream = new MemoryStream();

        }

 

        public void DoSomething()

        {

            ThrowExceptionIfDisposed();

 

            // … something

        }

 

        protected override void DisposeManagedResources()

        {

            if (fileStream != null) fileStream.Dispose();

            if (memoryStream != null) memoryStream.Dispose();

        }

    }

Obviously, you can’t use the Disposable base class if you’re already inheriting from another base class so in that case you’d still have to implement the IDisposable interface.

Update: Here’s a thread-safe version of this idea.

Here’s the situation: i have a domain model that is continuously kept in memory. There is a facade in front of this domain model which exposes some methods to make changes to the objects of the domain model. These methods can be called by consumers of the facade at any time. The in-memory domain model is also periodically updated by an update process. While this update process is running, any change that is requested through the facade needs to be queued for later execution (when the update process is finished). There is no persistent storage and any queued method calls do not need to be persisted either.

At first, i thought about mapping incoming method calls on the facade to ‘message’ objects which would contain all the needed information to perform the operation. The operation could then be performed by a piece of code that uses the values in the ‘message’ object. It sounds like a sound approach, and it would probably be necessary to use this if the queued method calls would need to be persisted. But that’s not a requirement. With that in mind, i figured i could take advantage of some of the new C# features to avoid having to map method calls to ‘message’ objects.

What i wanted was to create a class you can just pass a piece of code too, and depending on a condition that you define, that piece of code is either executed immediately, or queued for later execution. Obviously, the caller needs some kind of feedback… you want to know if your operation succeeded, if it failed, what the possible failure was or if it was queued. And if it was queued, you want to be able to retrieve the result of the operation later on. So i started playing around… the first thing i’d need was the following class:

    public class ExecutionResult

    {

        public bool Succeeded { get; set; }

        public bool Failed { get; set; }

        public bool Queued { get; set; }

        public Exception Exception { get; set; }

        public Guid QueuedOperationId { get; set; }

    }

If i use instances of this class as the return value of the operations, i can get all the feedback i need. I also need something to group a piece of code with an identifier:

        public class Operation

        {

            public Action Action { get; set; }

            public Guid Id { get; set; }

        }

The Action property can contain any piece of code which you can then identify through the Guid Id property.

Now we can implement the ConditionallyQueuedExecutor class (the name sucks, but i couldn’t find one that sucked less). First, we need a queue of Operations and we also need to store the results of operations that were queued and executed later on:

        private readonly Queue<Operation> operationQueue =

            new Queue<Operation>();

        private readonly Dictionary<Guid, ExecutionResult> resultsOfQueuedOperations =

            new Dictionary<Guid, ExecutionResult>();

I also want to be able to provide a default condition that should be checked when we try to execute a piece of code:

        public Func<bool> DefaultCondition { get; set; }

And then of course, we must offer a way to either perform the given piece of code, or to add it to the queue:

        public ExecutionResult DoOrQueue(Action action)

        {

            return DoOrQueue(DefaultCondition, action);

        }

 

        public ExecutionResult DoOrQueue(Func<bool> condition, Action action)

        {

            if (condition())

            {

                return TryToRun(action);

            }

            else

            {

                return AddToQueue(action);

            }

        }

I added an overload that allows you to pass in a specific condition for greater flexibility. So what does this do? As you can see, it merely checks the passed in condition, and if it returns true it will try to run the given piece of code. If it returns false, we add the piece of code to the queue.

The TryToRun and AddToQueue methods look like this:

        private ExecutionResult TryToRun(Action action)

        {

            var result = new ExecutionResult();

 

            try

            {

                action();

                result.Succeeded = true;

            }

            catch (Exception e)

            {

                result.Failed = true;

                result.Exception = e;

            }