Composite Pattern and Unity IoC container
Joel Spolsky thinks that IoC containers are an overkill and Dan North agrees that IoC Containers inadvertently tolerate highly inter-dependent designs. IoC containers, in my opinion, are indispensable in creating a loosely coupled application. So much so, that I think that there should be a language that has Dependency Injection built-in.
That aside, I have discovered a feature in Unity container that makes implementing a composite pattern kinda fun. Just a brief remainder of what the composite pattern is. It is a simple pattern where a class implements an interface and delegates invocation on that interface to an internal collection of actual interface implementations. This allows the calling class to treat multiple implementations as one single component.
Generally, this pattern is most appropriate for interface containing methods that have a simple return type or void ( i.e. Command Pattern). I found that things that are called “SomethingPolicy” are a good match for this pattern. In this example I will use ASP .NET authorization as an example of how to create a true Open-Closed component using a composite pattern.
For the sake of clarity I will call the class implementing the composite pattern composite class and actual implementations implementation interfaces.
The implementation of this pattern relies on a couple of interesting Unity Container properties.
Property 1: Items registered with a name are not resolvable through
Resolve(). Also remember that a
Resolve() call is the same as taking a dependency on that type in the constructor. These registrations are only available when calling
Property 2 Items registered without a name are not available when calling
ResolveAll() and are only available as a result of a call to
This means that you can register the composite class without a name and implementation interfaces as mappings with name. The composite class then becomes the default implementation - i.e. when someone takes a dependency on that interface in the constructor.
This question describes how to create a base controller that overrides
OnAuthorization() method and allows to require authorization by default, without having to decorate all action methods with
So, here is the base controller:
Below is the composite class. Note that it takes a constructor parameter of an array of mappings of implementation interface registration to the order in which it should be executed. This allows fine tuning the order in which the policies are executed. Note the near textbook following of SRP, where the logic of executing multiple policies and ordering of invocations is kept out of the controller class. The reason for this collection being an array of key value pairs as opposed to a dictionary is for ease of configuration through XML configuration.
The registrations for all of these can be done as follows:
That’s it. The configuration for XML is not included here as it is pretty much the same as the API version. There is a trick to get the
KeyValuePairs to work using a converter, but that’s a topic for another post.
blog comments powered by Disqus