Wrapping unity attributes ?

Sep 3, 2008 at 8:50 AM
Could someone please help me out substituting Unity's [ServiceDependency], [InjectionConstructor], ... attributes with my own naming, like [MyOwnServiceDependency], keeping Unity's default reflection and wireup strategies ? I need this to completely wrap unity, so that in case we decide to replace Unity with say Spring or another DI framework, we can try to at least bridge our usage of Unity attributes with the possibilities offered by the other framework.

Wrapping the Unity programmable API is much easier, wrapping the Unity XML is of course also a considerable task, but seems possible.

I'm thinking of writing a Unity extension, replacing appropriate parts of the ObjectBuilder policy management ?
Sep 4, 2008 at 4:35 AM
I recommend sticking with constructor injection, it doesn't require any attributes. If you have to use property injection, you could write an extension that attempts to set all properties that it can satisfy, sounds like trouble though.
Sep 4, 2008 at 5:36 AM
Thanks for the suggestion. Actually constructor injection is one of the reasons why we'd like to overwrite the [InjectionConstructor] attribute. It's quite cumbersome to use the API like container.Configure<InjectedMembers>().ConfigureInjectionFor<T>(new InjectionConstructor(...)) pointing Unity in the right direction when choosing constructors. It seems a lot easier to just decorate the right constructor. At the moment we're using setters instead.
Sep 4, 2008 at 3:43 PM
If the main reason you are wanting to wrap the API is for future container replacement, you might want to check out the project formally known as Prism.  They use an interface to abstract the container, IContainerFacade. They then have an adapter for the specific container,UnityContainerAdapter : IContainerFacade.  It might be worth your time to see how they put that together and use something similar.

Sep 5, 2008 at 5:44 AM
Edited Sep 5, 2008 at 5:46 AM
Prism (Composite WPF) also looks interesting, but we're already deep into Unity (having extended and wrapped the API) and have accepted the Unity XML format for specifying type mappings (no wrapping). We've done something similar to Matthew Podwysocki's anti-corruption approach (http://weblogs.asp.net/podwysocki/archive/2008/03/27/ioc-and-unity-configuration-changes-for-the-better.aspx), and among other things we've added controlled support for container scoping in our application along with a Unity EventBroker extension. So, the last obstacle really is to somehow wrap the attributes and thereby gain the flexibility of doing type mappings both in code and XML, and at the same time clear the pathway to switching the DI framework to ie. Prism.
Sep 5, 2008 at 6:35 AM
The attributes are only used in one place - the corresponding selector policies. In specific, DefaultUnityConstructorSelectorPolicy, DefaultUnityPropertySelectorPolicy, and DefaultUnityMethodSelectorPolicy. Well, ok, that's three places. ;-)

Take a look at those classes, and at the UnityDefaultStrategiesExtension class to see how they're installed in the container. You can create your own selector policies to replace the default and do whatever you like.

Sep 15, 2008 at 12:14 PM
And that was all there was to it! Copying the three selector policies, renaming the classes and creating a new extension using Context.Policies.SetDefault to override the default policies was a piece of cake.

 -- Thanks for the help


PS: The property selector policy is based on the DependencyResolutionAttribute instead of the concrete DependencyAttribute, is this deliberate ?
Sep 15, 2008 at 4:27 PM
Yes, that was deliberate. DependencyResolutionAttribute is more than just a marker; there's some actual logic in there. And the logic is replacable by subclassing.
May 8, 2009 at 6:26 PM
Edited May 8, 2009 at 6:26 PM

Are there examples any one can share as to how to wrap unity in custom code so that the reference to unity can be isolated?  I am particularly interested in wraping [Microsoft.Practices.Dependency] 

May 15, 2009 at 6:15 AM
Edited May 15, 2009 at 9:55 AM

Please look to the before mentioned anti-corruption approach for an example on how to wrap Unity.

The only reference to the Unity dll is when creating the implementing class of IDependencyResolver -- use a factory to decouple the actual creation.

Mar 30, 2010 at 7:02 AM

I have little sample application demonstrating extending Unity with support for custom attributes here:

It is not exactly wrapping of Unity attributes but I do not see why this aproach could not be used for any attribute.