Just trying to make sense of things...

ObjectBuilder Documentation

Thursday, 4 October 2007 15:48 by jordan.terrell

I've heard many times both in conversation and in blog posts that ObjectBuilder doesn't have any documentation.  Granted, yes it doesn't have good (if any) official documentation.

However, the Composite UI Application Block (CAB for short) does have a good bit of documentation on ObjectBuilder in the hands-on-labs (VB version, if you are so inclined).  Section 8 will give you a full architectural run down, which to me is far more valuable than class-by-class documentation.  After that, the best source of documentation is probably the source code.

Anyone else know of any good documentation for ObjectBuilder, official or otherwise?

Excellent Post by Jeremy on Dependency Injection

Friday, 7 September 2007 13:23 by jordan.terrell

A very well reasoned, thought out post on the use of dependency injection:

Type Mocking Dangerous in Static Languages

Monday, 27 August 2007 22:36 by jordan.terrell

Both Ian Cooper and Scott Bellware wrote excellent posts comparing dynamic and static languages, and how type mocking is dangerous when your using a static language (e.g. C#, VB.NET).  Scott said: "Type mocking might save your bacon when you have made poor design decisions along the way..."  I couldn't agree more!  Ian also talked about how dynamic languages leverage Duck Typing to overcome this danger.

Take a look at my friend's Duck Typing library - it's made to be used within a static language.  It too can "save your bacon" when you need to isolate legacy, tightly coupled code that you need to change and test.

You're All Applying the Dependency Inversion Principle

Monday, 27 August 2007 11:12 by jordan.terrell

John has posted a few comments on my previous post about the Dependency Inversion Principle (DIP) debate.  He raised a few questions and the more I thought about it, I felt it warranted a follow up post.

First, when it come to adding support for change ahead of the change, balance is always needed.  No one can future proof their software solutions against change - you'll end up with a ton of infrastructure code that only adds complexity and very little of the value originally intended.  However, change will happen.  Adding support of that at the junction points between tiers/layers is the responsible thing to do in all but the smallest of applications.  Again, balance is always needed - it can be easy to go to far with this.

Next, to answer John's specific questions: "It is the price of the tool that you are worried about?  The commercial support?"  Answer: Yes and no.  The price point is always a concern, as licensing is usually based on the number of computers that it will be installed on.  I appreciate having the right tools for each project, but sometimes the project's budget doesn't include monies for licenses to developer tools - besides Visual Studio.  This is not to say that I'm completely apposed to commercial tools - I'm a large fan of CodeSmith Professional, and I have recommended its use on many projects.    The thing about CodeSmith, however, is that its use doesn't affect the design characteristics of my application.  I can choose to apply the DIP or not, all the while using CodeSmith.  That is the point that I'm getting at - I don't want the selection of a development tool¹ to drive how certain design principles (e.g. Dependency Inversion, Single Responsibility, Open-Closed, Loose Coupling, High Cohesion) are achieved.  John and others have suggested that TypeMock could be used to achieve certain desirable design characteristics.  Take TypeMock away, and I fear in most cases (not all) that you would be left with an non-testable, highly-coupled design.

It has been suggested by those opposed to the DIP in this debate that the only reason developers are using the DIP is because of the use of mocking frameworks in their unit test.  I can see how that perception could easily be arrived at.  When applying the DIP, it provides many testing seams that can be leveraged by a mocking framework.  Let's stop for a second and ask, why is that?  It is because applying the DIP allows one to achieve a measure of loose-coupling.  But with all principles and patterns, a balance is needed.  I do not try to make all class-to-class interactions happen through interfaces; that would be unreasonable.  More often I use it when bridging the connection between tiers/layers of an application (e.g. business layer to data access layer).

You're Applying The Dependency Inversion Principle - You Just Might Not Know It

One of the wonderful things about this field of work is that there are many numerous ways that a principle or pattern can be applied.  There are many ways to arrive at a software solution for a problem - not always right or wrong, but better or worse.  It seems in all of this discussion about using DIP that it somehow became synonymous with using interfaces passed in via constructors, methods, or properties.  This is an incorrect viewpoint.  There is no requirement in the DIP that says interfaces be used, or that it requires the use of constructors, methods, or properties.  Principles can be adhered to many different ways. Dependency Inversion is just that - a principle - not a concrete implementation approach.

Jacob Proffitt said that he would prefer to use providers (abstract factories) instead of DI.  Great - it's still applying the Dependency Inversion Principle!  The Inversion part comes in you use some form of configuration to determine which concrete implementation of the provider will be used at runtime.  You can always implement something into your solution which lets you intercept the request for the provider and return a mocked version - that is if your provider framework allows this.

A Different Approach

I had hinted in a previous post on an approach that I've used in the past based on the Scope<T> MSDN sample.  I whipped² together a sample of this approach for you to take a look at.

First, there is a simple static class that provides simple and clean access to retrieving dependencies (IoC stands for Inversion of Control):

   1:      public static class IoC
   2:      {
   3:          public static T Resolve<T>()
   4:          {
   5:              return Resolve<T>(null);
   6:          }
   8:          public static T Resolve<T>(string name)
   9:          {
  10:              return IoCScope.Current.Resolve<T>(name);
  11:          }
  13:          public static IoCScope Register<T>(T target)
  14:          {
  15:              return Register<T>(target, null);
  16:          }
  18:          public static IoCScope Register<T>(T target, string name)
  19:          {
  20:              return IoCScope.Current.Register<T>(target, name);
  21:          }
  22:      }


Next, we have an abstract base class that represents an individual IoCScope, and well as manages the stack of nested IoCScopes.  One nice thing about this implementation is that it allows scopes to be defined for an entire AppDomain, or for just one thread:

   1:      public abstract class IoCScope : IDisposable
   2:      {
   3:          private static Stack<IoCScope> _AppDomainScopes = null;
   5:          [ThreadStatic]
   6:          private static Stack<IoCScope> _ThreadScopes = null;
   8:          internal static IoCScope Current
   9:          {
  10:              get { return GetCurrentScope(); }
  11:          }
  13:          private static IoCScope GetCurrentScope()
  14:          {
  15:              if (_ThreadScopes != null && _ThreadScopes.Count > 0)
  16:                  return _ThreadScopes.Peek();
  18:              if (_AppDomainScopes != null && _AppDomainScopes.Count > 0)
  19:                  return _AppDomainScopes.Peek();
  21:              return null;
  22:          }
  24:          private bool _IsAtAppDomainScope = false;
  26:          public IoCScope() : this(false)
  27:          {
  28:          }
  30:          public IoCScope(bool appDomainScope)
  31:          {
  32:              _IsAtAppDomainScope = appDomainScope;
  34:              Stack<IoCScope> scopeStack = GetScopeStack(_IsAtAppDomainScope);
  35:              scopeStack.Push(this);
  36:          }
  38:          private Stack<IoCScope> GetScopeStack(bool isAtAppDomainScope)
  39:          {
  40:              if (isAtAppDomainScope)
  41:                  return _AppDomainScopes ?? (_AppDomainScopes = new Stack<IoCScope>());
  42:              else
  43:                  return _ThreadScopes ?? (_ThreadScopes = new Stack<IoCScope>());
  44:          }
  46:          public void Dispose()
  47:          {
  48:              if (_IsAtAppDomainScope)
  49:                  TearDownScope(_AppDomainScopes);
  50:              else
  51:                  TearDownScope(_ThreadScopes);
  52:          }
  54:          private void TearDownScope(Stack<IoCScope> scopeStack)
  55:          {
  56:              if (scopeStack.Peek() != this)
  57:                  throw new ApplicationException("IoCScope disposed in wrong order.");
  59:              scopeStack.Pop();
  60:          }
  62:          public abstract T Resolve<T>(string name);
  63:          protected abstract void RegisterCore<T>(T target, string name);
  65:          public IoCScope Register<T>(T target)
  66:          {
  67:              RegisterCore<T>(target, null);
  68:              return this;
  69:          }
  71:          public IoCScope Register<T>(T target, string name)
  72:          {
  73:              RegisterCore<T>(target, name);
  74:              return this;
  75:          }
  76:      }


IoCScope is an abstract class because it allows you to implement registration and resolution of dependencies using your favorite IoC framework, or to write your own.  Assuming you've created one called MyScope, you can wire up dependencies via code this way:

   1:  using(MyScope scope = new MyScope())
   2:  {
   3:      scope.Register<ISomeService>(new SomeConcreteService());
   4:      ...
   5:  }


This registers an instance of SomeConcreteService with the current scope.  In can now be retrieved this way:

   1:  ISomeService svc = IoC.Resolve<ISomeService>();
   2:  svc.DoSomeWork();


Within the context of a unit test, you can define a new scope and register mocked instances of services that your component under test depends on.


I guess my overall message is this: You're all applying the DIP, just in different ways, so stop attacking it!  If you dislike the concrete approach that a large group of developers are using, let's talk about that.


Nitpicker's Corner

¹I'm not referring to the .NET Framework or 3rd party libraries you would add a reference to - naturally those should have an effect on your design.  I'm speaking of tools used by the developer in the process of writing the software's code.

²So don't expect a feature complete, error-hardened library.  If you choose to use this code in anyway, you accept that I am not responsible for what results, directly or indirectly.  If this sample seems rushed - it was.  If you'd like to have me send you a working Visual Studio 2005 project, request it via a comment on this post and I will send it your way.