Concepts like Dependency Injection and using an Inversion Of Control container have gradually gotten more popular and accepted in the .NET world in the last 2 years or so.  There are however still quite a few people who doubt the validity of these concepts.  Quite a few of these people seem to think that Dependency Injection for instance is only useful to increase the testability of your code. I wanted to go over a real world example which shows a (IMO) huge benefit which can be solely attributed to thinking about loose coupling, using Dependency Injection and using an Inversion Of Control container.

I recently wrote a post about how you can use an Agatha service layer fully in-process instead of having to host it in a different service through WCF.  The only reason why it’s so easy to do that, is because Agatha’s design makes heavy use of loose coupling and dependency injection.  And obviously, it makes use of an Inversion Of Control container to manage the dependencies and to wire everything together.

There are basically 3 very important parts to Agatha.  The first is the Request Processor.  This class basically delegates the handling of each incoming request to its corresponding request handler.  The other important parts are the Request Dispatcher (for synchronous client-side usage) and the Asynchronous Request Dispatcher (for asynchronous client-side usage).  I’ll just refer to these two classes as the request dispatchers for the rest of this post.  When the service layer is hosted through a WCF service, the request dispatchers need to communicate with the Request Processor through a proxy (either a synchronous one, or an asynchronous one).  It would’ve been very easy to tie the implementations of the request dispatchers directly to the implementation of the WCF proxies.  If i had gone that way, i wouldn’t have been able to offer the ability to run the service layer in process though, since the request dispatchers would require the WCF proxies to be used.  I could’ve hosted the WCF service in process, but that would really be overkill if you don’t really want to use WCF.

As easy as it would’ve been to tie the request dispatchers directly to the proxies, it was just as easy to make them depend on a slightly more abstract component.  There are two interfaces to communicate with the Request Processor:

Notice that there are no WCF attributes on these interfaces.  I have two more WCF-enabled interfaces, namely the IWcfRequestProcessor and the IAsyncWcfRequestProcessor.  They define the same methods as their non-WCF counterparts, but have all of the required WCF attributes placed on top of those methods.

Typically when creating (or generating) a WCF proxy, the proxy will only implement the interface of the service contract (in this case, that would be the IWcfRequestProcessor or the IAsyncWcfRequestProcessor interface).  Any class that would want to use these proxies would then need an instance of that proxy to be able to communicate with the WCF service.  In Agatha’s proxies, i chose a slightly different approach.  They implement both the WCF interface as well as the none-WCF interface.  Since the method definitions are identical, this doesn’t require any more work.  Take a look at the class definitions of those proxies:

As you can see, both proxy classes inherit from WCF’s ClientBase class and pass the WCF-specific interface as the generic type parameter to ClientBase.  That means that these proxies can execute the WCF operations defined in the WCF-specific interface.   These proxy classes also implement the original interfaces, which means that these proxies can be used by any class which requires an instance of IRequestProcessor and IAsyncRequestProcessor.

In Agatha, there is no class that directly uses either the RequestProcessorProxy or the AsyncRequestProcessorProxy class.  Instead, the request dispatchers depend solely on IRequestProcessor or IAsyncRequestProcessor:

The dispatchers never know exactly who they’re talking to.  This means that they can communicate either through a WCF proxy, or the real Request Processor, depending on how your Inversion Of Control container is configured.

That is a huge benefit because it gives you a tremendous amount of flexibility when it comes to how you want to use your service layer (in process, in another service, on another machine, whatever) and it really didn’t take any extra effort with regards to development time to achieve that flexibility.  If i want to use Agatha with a different communication technology, then i could do so by simply creating implementations of the IRequestProcessor and IAsyncRequestProcessor interfaces which deal with the specifics of whatever that different communication technology might be.  I would also have to change the way the implementations are registered with the Inversion Of Control container to make sure that the new implementations are used.  But i wouldn’t have to change anything else.

In this case, dependency injection and loose coupling was not used to increase testability.  The increased testability that comes from using this approach is an added bonus.

We’re experimenting at work with a bit of a different approach as to how we structure our views and how they will interact with each other. We already know that our views will be reused in many different contexts so having them communicate with other views is something that needs to be done in a very loosely coupled manner. I don’t want any of the views to even know about the existence of other views, let alone having them know about specific instances of them.

But these views do have to interact with each other. I didn’t want to use typical events because that would require either a certain view to know about another view to be able to subscribe to its events, or you’d need some other component which knows which views need to be hooked to each other. We really need maximum flexibility for what we have in mind with our views, so it only made sense to finally start using the Event Aggregation pattern. The idea is that a view can basically publish events, without knowing who is subscribed to these events, and that suscribers will be notified whenever these events occur. However, subscribers don’t know anything about who is publishing the events. Instead, both publishers and subscribers only know of the Event Aggregator. A publisher tells the aggregator to publish an event to all subscribed listeners for that event. Each subscribers simply tells the aggregator “i’d like to be notified whenever this event occurs, and i don’t care where it comes from”.
Plenty of implementations of this pattern can be found online already, so i figured: why not add my own? :p

Fist of all, an event is nothing more than a class that inherits from this class:

Every event should inherit from this class, and add whatever necessary properties that are important for that particular type of event.

If a class is interested in listening to a specific event, it needs to implement the following interface:

If a class is interested in multiple events, it simply needs to implement the generic IListener interface for each type of event that it wants to handle.

Then we obviously need the Event Aggregator. I wanted an aggregator that allowed listeners to either subscribe/unsubscribe to/from very specific events, or just subscribe/unsubscribe to/from whatever it supports. So i have the following IEventAggregator interface:

The Subscribe and Unsubscribe methods that simply take an IListener reference will either subscribe or unsubscribe the given listener to/from every event that it can handle. In other words, for every generic IListener interface that it implements. Yet you also have the ability to subscribe/unsubscribe from a specific event type.

And here’s the implementation:

In case you’re wondering… the IDispatcher interface is merely a way to wrap Silverlight’s real Dispatcher. We wrap it so we can use a different implementation of the IDispatcher in our automated tests. Other than that, the implementation is very straightforward.

We started using this very recently, so this implementation might change in the upcoming weeks, but for now it does what it needs to do and it does so pretty well. In our case, every view’s Presenter automatically has an IEventAggregator property so whenever we need to publish an event, we can simply do something like EventAggregator.Publish(new SomeEvent(someParameter)). Or, Presenters that need to listen to events can simply say EventAggregator.Subscribe(this) or only subscribe to some specific events whenever they need to and their specific Handle method will be called whenever someone publishes the event. This also allowed us to get rid of the somewhat awkward syntax when testing events (subscription, unsubscription and the actual handing of events) with mocking frameworks.

And as a last bonus, i put a call to the Unsubscribe(IListener) method in the Dispose method of our base Presenter implementation. Which means that none of them will be left subscribed to events by accident anymore

If you have a web application which communicates with a remote service, it’s important to protect that web application from any problems the remote service might be dealing with. For instance, if the remote service goes down (for whatever reason) you really don’t want your application to keep making calls to this service. These failing calls increase the load on the service, which is already having problems, and will also block your threads which takes away resources from your application to deal with other requests. One pattern which is very suitable to reduce the problems for this situation is the Circuit Breaker (read that unless you’re familiar with the circuit breaker).

The biggest issue i have with my previous implementation is that it required you to call it manually to protect potentially risky calls. I don’t like having to call my circuit breaker whenever i want to make a service call because as a consumer of a service proxy, i shouldn’t even know about the circuit breaker. I also don’t want any coupling between my service proxy and the actual circuit breaker. Sounds like a good candidate for some AOP magic, right?

We’re going to use Castle Windsor’s Interceptors to make this work. First, the implementation of the CircuitBreaker class:

Notice how the CircuitBreaker class implements Windsor’s IInterceptor interface. The Intercept method will be called by Windsor whenever we try to call a method from a protected component. Within the Intercept method we can add the necessary logic to apply the Circuit Breaker pattern to the code that was originally called.

Now we just need to configure the Windsor IOC container to apply this bit of AOP magic for us.

First, we register the CircuitBreaker with the container:

Notice that we register the CircuitBreaker implementation with a Singleton lifestyle, a custom name and the required constructor parameters to create an instance of the CircuitBreaker.

Then we register our service proxy:

Notice how we registered the service proxy as a transient component, while referencing the singleton CircuitBreaker interceptor. This means that each resolved instance of our service proxy will be protected by the same CircuitBreaker instance. If you have multiple services that you want to protect, simply register multiple CircuitBreakers with different keys and link each service you want to protect with the correct CircuitBreaker key.

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:

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:

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:

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:

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

Update: i also have a complete series of posts on this which you may find interesting.

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:

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:

And the response would look like this:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

Note: you can find a more recent post on this concept here.

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

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

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:

The TryToRun method is pretty straightforward… it tries to execute the given piece of code, and if it worked without exceptions it returns a successful ExecutionResult instance. If an exception was caught, it returns a failed ExecutionResult which contains the original exception. The AddToQueue method is also pretty straightforward: it combines the given code with a Guid and stores the two values in an Operation instance. That instance is added to the queue and the returned ExecutionResult contains the identifier of the queued operation, which can be used later on to retrieve the ExecutionResult once the operation in the queue has actually been executed.

So how are the operations in the queue executed? Instead of going for a smart and fancy auto-detection scheme based on the condition i went for a simple public method that has to be called explicitly:

As you can see, it tries to execute each operation in the queue, and it stores the ExecutionResult in a dictionary with the operation’s identifier as the key value.

The original caller can then retrieve the final ExecutionResult through this method:

And that’s it basically. You can now use this class like this:

Obviously this is just a fake example, but you get the idea.

I wrote this code last week, and i’m still not sure what to think of it. I kept it all pretty explicitely: the queued operations need to be triggered by a method call, the final ExecutionResults need to be retrieved by a method call… Surely, it would be possible to make this all work a bit more automagically, no? It actually is possible but i’m affraid it would make the whole thing much harder to understand. And it might be hard to understand as it is already. The example above also isn’t thread-safe (the real version is, but i kept the thread-safety stuff out of this code for clarity) and you currently have no way of dealing with return values of the code that you want to execute. But you could easily make the ExecutionResult a generic class with a generic ReturnValue property to store the given code’s return value in if that were necessary.

Sometimes, you’ve got a bunch of actions that you need to execute in a loop. The problem is that those actions are all performed synchronously so this could take some time depending on the action. But, if the action itself is thread-safe, and the actions are not dependent on the results of previous actions, you might get much better performance if you spread that workload over a few different threads. Especially if you have multiple CPU cores.

Wouldn’t it be cool if you could do something like this:

Note: the reason why you need to use a new variable inside the loop is to avoid that the ‘input’ variable (not the reference to the object, but the actual variable) is captured by the anonymous method. If you don’t use a new variable, each created anonymous method would refer to the ‘input’ loop variable, which by the time all the tasks are executed points to the last Input instance in the inputs collection. The result would be that each task is executed on the same input instance. This is a known issue with variable capturing and anonymous methods.

Anyways… the code above basically spreads the workload over the given number of threads.

The rough, not-quite-production-ready code of the MultiThreadedTaskExecutor class looks like this:

So how does it work? It uses a queue to hold each task that was added by the consumer of the class. It creates the given amount of threads and also creates an EventWaitHandle for each thread. Then when the user starts the execution with a call to RunTasksAndWait, each thread is started and then the call to RunTasksAndWait will wait until each thread is finished. In the meantime, each thread will get the next task off the queue and executes it. If an exception is thrown within the task, it is caught and is either swallowed or rethrown (the consumer can add exception types that can be swallowed). Each thread keeps doing this until it can’t get a new task off the queue. When that happens, the thread signals the EventWaitHandler and then it dies. When all threads are dead, RunTasksAndWait will stop blocking and control is returned to the caller. All of the tasks have been executed and the workload has been spread over the given amount of threads.

Note: due to the call to WaitHandle.WaitAll, this won’t work on STA threads because the implementation of WaitHandle.WaitAll simply throws a NotSupportedException on STA threads.

Keep in mind that this is a rough version of this code… it definitely needs a bit more polish (better exception handling for when the threads are interrupted and stuff like that mostly) but you get the idea

But if you know a better way to do this, or if you spot flaws in this implemenation, i’d love to hear about it

One of the coolest patterns discussed in Release It is the Circuit Breaker pattern. The pattern enables you to wrap dangerous or risky operations with a component that avoids calling the real operation when a certain failure rate has been reached. For instance, suppose you need to call an external web service in your application. The external web service is known to be flaky at times which causes each call to it to hang for a while before it eventually fails. Now, if that service is in a bad state, your application threads will waste a lot of time waiting on the failure. Wouldn’t it be better if your application could detect when the service is in a bad shape and in that case, immediately throw an exception when the service is called? As the author of Release It often says: it’s better to fail fast if you know something’s wrong.

The Circuit Breaker pattern allows you to do this pretty easily. The Circuit Breaker basically has 3 states: Closed, Open and HalfOpen. When in Closed state, each call to the protected resource is allowed. But each time it fails, a failure counter is incremented, and when the failure counter reaches a configurable threshold, the Circuit Breaker moves to the Open state. When it moves to Open state, it starts a timer set to elapse at a configurable timeout value. If the timeout has not been reached, each call to the protected resource is not allowed, and an exception is thrown to indicate that the Circuit Breaker is not allowing calls at the moment. When the timeout has been reached, the Circuit Breaker moves to HalfOpen state. In this state, the next call to the protected resource is allowed, but if it fails, the Circuit Breaker immediately switches back to the Open state and the timeout period starts again. If the call to the protected resource while in HalfOpen state succeeds, the Circuit Breaker switches back to the Closed state. I hope i explained it clearly, i didn’t really find a good explanation of the Circuit Breaker pattern online… one more reason to buy the Release It book i suppose

Anyway, let’s try implementing a Circuit Breaker in C#. Since the Circuit Breaker operates differently depending on its State, this is perfect candidate for using the State pattern. First, lets define the CircuitBreakerState class:

Pretty simple stuff so far… There are 3 virtual methods that will be called by the CircuitBreaker. I think the names speak for themselves so you shouldn’t have any problem figuring out when these methods will be called. Each derived state simply needs to plug in its necessary logic in the right method and then the right logic will be executed at the right time, according to the state the CircuitBreaker is in.

Let’s take a look at what should happen when the CircuitBreaker is in Closed state:

When a Closed state instance is created, it resets the failure count of the CircuitBreaker. When an exception is thrown by the protected code, the failure count is increased (the CircuitBreakerState base class does this) and then we check if the failure threshold has been reached and if so, we instruct the CircuitBreaker to move to the Open state.

This is how the Open state looks:

When an Open state instance is created, it starts a timer which is set to elapse when the CircuitBreaker’s timeout period has been reached. When the timeout has been reached, the CircuitBreaker is moved to the HalfOpen state. When the protected code is about to be called when we’re in this state, we throw an OpenCircuitException to prevent the protected code from being called.

This is what the HalfOpen state looks like:

If an exception is thrown by the protected code while we’re in this state, we immediately move back to the Open state to prevent the protected code from being called again. But if the protected code has been called without exceptions, we can move back to the Closed state.

We’ve implemented all the state-based logic in these state classes. Now we can easily implement the CircuitBreaker. When you create the CircuitBreaker, you pass the failure threshold and the timeout period to the constructor. After that, you can pass any code block to the AttemptCall method.

Here’s the full code of the CircuitBreaker:

Here’s a small example of how you could use it:

You can download the solution (code + tests) here.