When It Comes To IOC Containers, We Seem To Be Pretty Loyal

I'm still working my way through my backlog of unread posts in Google Reader (not even halfway through it :s) and one thing I noticed by reading some posts is that we (.NET developers) generally seem to be pretty loyal when it comes to which IOC container we use. Some of us might switch between different containers from time to time, but I get the feeling that most of us typically stick with the container that we've come to know the best.

Some people will stick with Castle Windsor, some swear by StructureMap, some will always use Autofac, some only want NInject... hell, I even know a few people who still prefer Spring.NET. The only one that doesn't seem to have many loyal followers is Unity ;). Every container has its strengths and weaknesses but most of them range from very good to downright excellent. When new features are introduced to one container, they often quickly find their way into the other containers as well. A cool new feature in container X is rarely a good incentive to switch containers because odds are high that your favorite container will get the new feature pretty soon as well.

What I think is a big reason of this (observed) loyalty is that the more you rely on your IOC container's power, the less likely you are to switch to another container out of fear that some things might behave differently or might not work the way you think or expect they will. If the container you've chosen to use has proved itself to you in production usage, you are very unlikely to replace it with another. After all, it's a very important piece of how your project works and you probably depend on it a lot. You've probably become very familiar with its behavior in different circumstances and you've either come to rely on that, or have learned to live with it in some way. But you've learned how it works and you're pretty sure that there are no unpleasant surprises that will pop up a couple of days or weeks after a new deploy. Because of that, I really wouldn't feel all that comfortable with switching to a new container. And lets face it, they all have their little special cases that you really need to know about to avoid problems.

And if you are using features that are unique to your container, then you're obviously even more unlikely to make a switch. In my case, I used Castle Windsor when I first started to use an IOC container. I ran into some issues with memory usage because of the way Windsor works, but once I learned that I always have to explicitly release any resolved components, the problems went away. In fact, I've come to rely on the fact that by releasing a resolved component, its disposable transient dependencies will automatically be disposed by Windsor as well. I'm not sure about this, but I think Windsor is the only container that does this, or at least one of the few that do. I actually consider it a must-have feature for a container, but most people don't seem to consider this as important.

I can't really imagine a situation that would make me consider switching to another container at this point... well, unless its development would someday halt obviously. And even then I'd probably be holding on to it for a long while. How about you? How likely are you to switch to a different container? And what would make you switch? What holds you back from switching to a different one? Which one do you use and why do you like it so much?

Written by Davy Brion, published on 2/15/2010 10:33:43 PM
Categories: inversion-of-control

Inversion Of Control Containers And Factories Aren’t Mutually Exclusive

Julian Birch recently posted a reaction to my reaction to Uncle Bob’s IOC lunacy post. Julian mistakenly thinks that I have a problem with using factories. I definitely don’t have a problem with using factories. I just have a problem with using them in the manner that Uncle Bob suggested in his post. Jeffrey Palermo also recently posted an example of where he thinks using a factory is better than injecting dependencies. I wanted to react to both those posts with a real-world example of where I prefer to use a factory and how I use an IOC container to do so.

As you probably know by now, I'm a big proponent of using IOC containers. I've never stated that they should be used in every single application, but using one certainly pays off in most applications, especially as complexity increases gradually. When you use an IOC container, you’ll have much less need for factories. There are however two situations where I certainly prefer to use a factory. And that is when:

• a certain dependency might not always be used by a class and that dependency is expensive to create
• I might need multiple instances of a dependency during the lifetime of a class

A good example of both those situations is when using Agatha’s AsyncRequestDispatcher class from a Silverlight user control. Creating an AsyncRequestDispatcher is expensive because it in turn requires an instance of the AsyncRequestProcessorProxy class. The AsyncRequestProcessorProxy class inherits from WCF’s ClientBase class, and those types are relatively expensive to create. And due to the asynchronous nature of those service calls, you can never deterministically dispose of a AsyncRequestDispatcher instance with absolute certainty that it won’t be disposed before the response of the service call is returned from the service. Because of that, the AsyncRequestDispatcher class was designed to dispose of itself automatically once the response is returned. This effectively means that you’ll need a new instance of AsyncRequestDispatcher whenever you need to make an asynchronous call to an Agatha service.

For most user controls, it obviously doesn’t make sense to inject one instance of the AsyncRequestDispatcher into the user control because you often need to make multiple service calls depending on user interactions or other events. A good way to deal with this is obviously to ask a factory to create the AsyncRequestDispatcher whenever you need one. Which is why Agatha offers the AsyncRequestDispatcherFactory class, which looks like this:<

Now, some of you are probably thinking: what is the difference between this and Uncle Bob’s example? Well, unlike Uncle Bob’s example this factory is not responsible for registering the required components to create an AsyncRequestDispatcher with the container. It merely resolves an instance and returns it. And yes, it uses the container to do so. I could actually just new up an AsyncRequestDispatcher myself but then the factory would also have to know about its dependencies and make sure it’d be able to create them. If those dependencies have dependencies of their own, I'm back to dealing with dependencies manually which is exactly what I'm trying to avoid throughout my codebase. I can’t come up with a single reason why this would be wrong, but some of you probably will so feel free to point out those reasons.

The benefit of this factory is that it enables me to delay the instantiation of an expensive dependency, and it also enables me to get more than one instance if I need to during the lifetime of a single object. At the same time, it doesn’t have any of the downsides of Uncle Bob’s approach. Also, this approach is something that you won’t need to resort to throughout your codebase, it’s more for edge-cases.

Now, how do we use this factory? Instead of new’ing the factory manually like Jeffrey does in his example, the factory is registered with the IOC container and I simply inject the factory into the class that needs to use it. This still enables me to change implementations of both the factory as well as the instances the factory needs to create. And it also makes it easy to stub or mock the factory during tests. I get all of the benefits from using Dependency Injection and an IOC container, and I have yet to notice any downsides to this approach. But again, I only use this approach in the 2 situations I mentioned in the beginning of this post. In most cases, you really don’t need factories anymore. And when you do, just leverage your IOC container to make the factory as simple and dumb as possible.

Written by Davy Brion, published on 1/23/2010 4:14:45 PM
Categories: dependency-injection , inversion-of-control

Dependency Injection Inversion Rejection

Uncle Bob has done it again. In his latest post, he actually advises people to go back to manual dependency injection instead of relying on a framework (our beloved IOC containers) to do it for us. You really ought to check out the post and his examples in particular. Done with that? Ok.

There are two major problems that I have with his post. The first is this one:

I like this because now all the Guice is in one well understood place. I don’t have Guice all over my application. Rather, I've got factories that contain the Guice. Guicey factories that keep the Guice from being smeared all through my application. What’s more, if I wanted to replace Guice with some other DI framework, I know exactly what classes would need to change, and how to change them. So I've kept Guice uncoupled from my application.

For those of you who don’t know, Guice is an IOC container from Google. Uncle Bob doesn’t want references of an IOC container spread out throughout his application, but he doesn’t seem to mind coupling his factories with his IOC container for some reason. He seems to think that he can actually switch to a different container more easily because of this, because he would only have to modify his factories.

Here’s the deal. If you have more than a handful of references to your IOC container in your code (apart from the registration obviously), then you really don’t know what using an IOC container is all about. Yes, I know Uncle Bob is supposed to be a legend. Yes, I realize that I'm saying that a legend in the OO world doesn’t seem to grasp some of the most important concepts of using an IOC container. Can you really disagree with that after reading his post?

His whole idea of making it easier to switch to another container with his approach is ludicrous. He would have to modify every single factory that he uses, and in his trivial non-real world examples that wouldn’t be a lot to do but out here in the real world, we’d end up with a boatload of those factories and they would all have to be modified. Conversely, if you’re using an IOC container in the way it is meant to be used, you’d only have to change your registration code and the one or two places where you resolve something manually through the container. And that’s it. Yes, you typically only need one or two places where you use the container directly. Well, unless you’re Uncle Bob of course.

My other problem with his post is with the sample that he uses. It really is a very simplistic example and the approach he outlines simply does not scale when you’re dealing with large, real-world codebases. His approach might work for the size of the examples in his books, or for the code of Fitnesse, but if I were to apply his recommended approach for some of the systems that we’re working on, it would lead to a terrible mess very quickly. Not exactly what I'd have in mind when thinking of Clean Code.

The one thing I do like about this post? Well, there are quite a few people who follow Uncle Bob blindly and can’t say a single bad thing about his thoughts/ideas/approaches. I know quite a few of them make extensive use of IOC containers and some of them are even involved in the development of these containers. Hopefully, Uncle Bob’s post will finally convince these people that blindly following anyone is simply never a good idea and that you have to keep a critical mindset for everything that you read, no matter who wrote it.

Written by Davy Brion, published on 1/19/2010 9:19:38 AM
Categories: dependency-injection , inversion-of-control

Real World Benefits From Loose Coupling, Inversion Of Control And Dependency Injection

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.

Written by Davy Brion, published on 12/10/2009 7:00:16 AM
Categories: code-quality , dependency-injection , inversion-of-control , patterns