ObjectBuilder Dependency Injection Framework

NEW POST: BuilderAware attribute

marten_range — Mon, 24 Mar 2008 23:13:40 GMT

I read the a discussion regarding performance an ObjectBuilder. That got me thinking along the lines of a builder aware attribute.

Often what I do when I implement a new strategy is that I've created an attribute that I wish should have semantics.

The process of the strategy is usually: iterate over all member infos, locate my attribute, perform action (depending on buildup or teardown).

I aimed to encapsulate this process in a builder aware attribute strategy. The benefit is also that since this strategy knows its working with builder aware attributes it scans and caches those that it finds. So the next time the same type is encountered it just loops over an array calling the buildup and teardown methods on the attribute. This should give an increased performance over having seperate strategies for each attribute.

I don't think this is a one size fits all solution to all strategies and this is only a rough beginning. However I thought it turned out rather nicely so I though I shared this with you.

My simplistic test case.

   /// <summary>
   /// MyBuilderAwareAttribute implements IBuilderAwareAttribute, it then gets buildup and teardown
   /// </summary>
   [AttributeUsage(AttributeTargets.Property)]
   public class MyBuilderAwareAttribute : Attribute, IBuilderAwareAttribute
   {
      public object BuildUp(IBuilderContext context, object buildKey, object existing, object attribute, MemberInfo memberInfo)
      {
         // Inject "Test"
         var l_pi = (PropertyInfo)memberInfo;
 
         l_pi.SetValue(existing, "Test", null);
 
         return existing;
      }
 
      public object TearDown(IBuilderContext context, object item, object attribute, MemberInfo memberInfo)
      {
         return item;
      }
   }
 
   public class MyClass
   {
      /// <summary>
      /// Inject "Test"
      /// </summary>
      [MyBuilderAware]
      public string Name
      {
         get;
         set;
      }
   }
 
   public static class Assert2
   {
      public static void True(
         Expression<Func<bool>> assert)
      {
         if (!assert.Compile()())
         {
            Assert.True(
               false,
               assert.Body.ToString());
         }
      }
   }
 
   public class BuilderAwareAttributeStrategyTest
   {
      [Fact]
      public void BuildCallsClassWithInterface()
      {
         var strategy = new BuilderAwareAttibuteStrategy();
         var context = new MockBuilderContext();
 
         context.Strategies.Add(strategy);
 
         var l_object = new MyClass();
 
         context.HeadOfChain.BuildUp(context, typeof(MyClass), l_object);
 
         // Validate property value indeed is "Test"
         Assert2.True(() => l_object.Name == "Test");
      }
 
   }

The interface

   public interface IBuilderAwareAttribute
   {
      object BuildUp(
         IBuilderContext context, 
         object buildKey, 
         object existing,
         object attribute,
         MemberInfo memberInfo);
 
      object TearDown(
         IBuilderContext context, 
         object item,
         object attribute,
         MemberInfo memberInfo);
      }

The strategy

   public class BuilderAwareAttibuteStrategy : BuilderStrategy
   {
      struct CachedAttributeData
      {
         public IBuilderAwareAttribute Attribute;
         public MemberInfo MemberInfo;
      }
 
      readonly Dictionary<
         Type,
         CachedAttributeData[]> m_cache = new Dictionary<
            Type,
            CachedAttributeData[]>();
 
      static CachedAttributeData[] BuildCacheElement(Type t)
      {
         var l_result = new List<CachedAttributeData>();
 
         var l_member_infos = t.GetMembers(
            BindingFlags.Instance
            |  BindingFlags.NonPublic
            |  BindingFlags.Public
            );
 
         for (var l_iter = 0; l_iter < l_member_infos.Length; ++l_iter)
         {
            var l_member_info = l_member_infos[l_iter];
            var l_attributes = l_member_info.GetCustomAttributes(true);
 
            for (var l_ita = 0; l_ita < l_attributes.Length; ++l_ita)
            {
               var l_attribute = l_attributes[l_ita] as IBuilderAwareAttribute;
 
               if (l_attribute != null)
               {
                  l_result.Add(new CachedAttributeData
                     {
                        Attribute = l_attribute,
                        MemberInfo = l_member_info,
                     });
               }
            }
         }
 
         return l_result.ToArray();
      }
 
      CachedAttributeData[] Lookup(Type t)
      {
         lock (m_cache)
         {
            CachedAttributeData[] l_result;
            if (m_cache.TryGetValue(
               t,
               out l_result))
            {
               return l_result;
            };
         }
 
         var l_new = BuildCacheElement(t);
 
         lock (m_cache)
         {
            // Potentially overwrites a duplicate value but it 
            // should be identical due to the immutability of Type
            m_cache[t] = l_new;
         }
 
         return l_new;
      }
 
      public override object BuildUp(IBuilderContext context, object buildKey, object existing)
      {
         var l_cached = Lookup(existing.GetType());
 
         for (var l_iter = 0; l_iter < l_cached.Length; ++l_iter)
         {
            var l_item = l_cached[l_iter];
 
            l_item.Attribute.BuildUp(
               context,
               buildKey,
               existing,
               l_item.Attribute,
               l_item.MemberInfo);
         }
 
         return base.BuildUp(context, buildKey, existing);
      }
 
      public override object TearDown(IBuilderContext context, object item)
      {
         var l_cached = Lookup(item.GetType());
 
         for (int l_iter = 0; l_iter < l_cached.Length; ++l_iter)
         {
            var l_item = l_cached[l_iter];
 
            l_item.Attribute.TearDown(
               context,
               item,
               l_item.Attribute,
               l_item.MemberInfo);
         }
 
         return base.TearDown(context, item);
      }
   }

Comments?

NEW POST: What would you like in OB 2.0?

marten_range — Mon, 24 Mar 2008 15:03:58 GMT

Derek:

I do agree with keeping the ObjectBuilder lean and mean. That's a big strength to it. But I wouldn't mind being able to download good and maintained implementations for interception or event broking together with OB. That's what I liked about OB 2 that the interception and event broking (and indeed also the injection part) was seperate from the core. Personally in my case I've certain restraints to how events can be broked so I can't probably use a general event mechanism. So I very much would like to not include the standard event broking in OB 2.0 in my project.

Still I see benefits of including such functionality, if nothing else as a good example on how to do it yourself if it shouldn't fit in your case.

Regarding Prism. That's sounds very interesting. Especially the part about getting compile-time errors because that's a weakness in how its done in CAB IMO (There are lots of strenghts that outweighs that weakness but a weakness nonetheless)

NEW POST: What would you like in OB 2.0?

derekgreer — Mon, 24 Mar 2008 02:08:20 GMT

One implementation detail I would recommend including with Object Builder is the simplest of facades that would serve as a container. If it had an instance based "ObjectFactory" type whose default constructor created default instances of the lifetime container, locator, and builder then it could be used out of the box. An object just such as this is what I've used as my container for several years now. As simple as this sounds, if the first version had provided a facade like this then I really feel Object Builder would have taken off a lot more than it did. I think the "assembly required" aspect of Object Builder prevented a lot of people from diving in. Of course, with Enterprise Library 4.0 we will finally have an out of the box container for Object Builder, so I expect 90% of people's exposure to Object Builder will be through Enterprise Library. Nevertheless, I think it would be good to have something that allows it to work out of the box for those few who download it directly.

Derek

NEW POST: What would you like in OB 2.0?

derekgreer — Mon, 24 Mar 2008 01:56:19 GMT

In my opinion, Object Builder shouldn't be bundled with an Event Broker. Object Builder should be kept lean and extensible, not bundled with implementation features. An event broker falls into an application library category, similar to having a service registry, command registry, etc. If the OB tam wants to make another Event Broker available then I would recommend making it a separate download bundle.

If you want a stand alone Event Broker then I would recommend waiting on Prism. Like CAB, Prism will contain a suite of application infrastructure components. Unlike CAB, one of the design goals of Prism is to make these components capable of being used independently. While I don't think the latest drop has an Event Broker yet, one is in the works. The preliminary design is to create a non-DI based broker which is delegate based rather than event based and uses interfaces as contracts rather than string-based event names. This is more efficient given you won't need to run objects through an EventBrokerStrategy and do reflection, will offer compile time type checking for both the contract and the EventArgs (i.e. no magic stirngs to get wrong and you can't get the wrong EventArgs type), and does away with the need for any weak reference maintenance.

Derek

NEW POST: What would you like in OB 2.0?

marten_range — Sun, 23 Mar 2008 22:13:48 GMT

I too like to see some configuration but I don't necessary think the Spring way is necessarily the best way. I love the attributed part of OB I think it gives great clarity. I would be satisified if there was some standard way to add/remove strategies and policies.

I'm also excited about the work been done with OB2.0. I think it is great to add event broking and interception to OB. As documented the eventbroking is simpler then the CAB variant. However, one of the truly brilliant benefits of CAB events was the possibility to add restrictions on the event sink. Ie run sink in publisher/background or GUI thread. I wish that for OB2.0, possible extensible also. Also, the event hierarchies like in CAB are extremely powerful (ie publish down a tree).

In conclusion I would like to add that at my company we are releasing a new way to develop functionality for our big ERP application written in C++. Future programmer will use .NET instead. A very important component for us in order to reduce coupling and increase testability is of course the ObjectBuilder. I stuck out my neck a little bit when I pushed for using OB as many programmers here are very new to IOC. However, OB has worked flawlessly and people are now seeing the benefits.

So thank you for this great technology.

NEW POST: Why is OB not DI container but a "framework"?

carballosa — Tue, 18 Mar 2008 16:19:29 GMT

In lots places, including this project's home page, I read: OB is not a DI container but a framework for building DI systems. Can anyone explain why?

NEW POST: Is ObjectBuilder dead?

MatthiasFG — Mon, 17 Mar 2008 07:01:05 GMT

Cool!
That's good news to me, 'cause I like the work you did and I would appreciate to see an adaption of ObjectBuilder2 in a major community product, like CAB/SCSF (reloaded) und EntLib.
Now this will happen with Unity and its integration within EntLib.

NEW POST: Is ObjectBuilder dead?

ctavares — Mon, 17 Mar 2008 06:59:46 GMT

I think you're overstating the departure. All the basics of OB are still in place, and a lot of the fundamental architectural improvements you made (hierarchical policy lists & strategy chains, for example) are all still present.

Yes, we did add new strategies that work radically different than the original onces. But that was done specifically to address performance issues, things that p&p customer have been complaining about for years. And yes, I did change the IBuilderStrategy interface. That was to improve debuggability. Neither of these things were on your original radar; I expect if they were you would have ended up in close to the same spot.

The interception and event broker stuff aren't in there, granted, but I thought that was the whole point of having them in separate assemblies? While I doubt a standard event broker will be part of the core package, we will be doing an interception system as an extension, and it'll probably be based on what you did (which, in turn, was based on what I did. :-) ).

NEW POST: Is ObjectBuilder dead?

scottden — Mon, 17 Mar 2008 02:08:52 GMT

Yes it will stay in place. We will see what happens over time.

NEW POST: Is ObjectBuilder dead?

BradWilson — Mon, 17 Mar 2008 01:08:40 GMT

The ObjectBuiler2 project being used by Unity is an adaptation of (and dramatic departure from, IMO) the work Scott and I did here.

NEW POST: Is ObjectBuilder dead?

MatthiasFG — Sun, 16 Mar 2008 20:13:37 GMT

As far as I've seen (build of 03/12), Unity uses ObjectBuilder2 as the object factory of its choice.
Will ObjectBuilder stay in place even for the release of Unity? Or will those guys switch to another object factory?

NEW POST: Is ObjectBuilder dead?

scottden — Fri, 14 Mar 2008 17:43:04 GMT

I believe it is a matter of choice. My biggest thing is to get people moving in the direction of container based development. The right one... the one that best fits your needs. I know some will only be able to use MS related code.... so Unity is your key... others can choose Windsor etc.

NEW POST: Is ObjectBuilder dead?

MatthiasFG — Fri, 14 Mar 2008 06:49:22 GMT

Nice to hear it's not dead.
But being a user of an DI framework, I wonder why you work on both, ObjectBuilder and Unity.
Wouldn't it make more sense to focus on one and making the decision, which one to use, easier for us users?

NEW POST: Is ObjectBuilder dead?

scottden — Fri, 14 Mar 2008 00:07:34 GMT

It is not dead. Just waiting to have a little life breathed into again. We will be making it work (a little different from Unity).

NEW POST: Is ObjectBuilder dead?

BradWilson — Thu, 13 Mar 2008 16:21:36 GMT

The P&P team is releasing something in the "ObjectBuilder2" namespace as part of Unity, but it is only very loosely based on the work that Scott and I did.

NEW POST: Is ObjectBuilder dead?

MatthiasFG — Thu, 13 Mar 2008 10:03:58 GMT

Hi there!

Reading about Unity and that Scott Densmore is part of the Unity guys and that Peter Provost quitted the p&p goup, I would like to know if the ObjectBuilder 2.0 is dead?

-Matthias

NEW POST: Using encrypted config files with ObjectBuilder

kimballjohnson — Sun, 24 Feb 2008 11:28:10 GMT

I am working with a secure implementation (at least I intend it to be secure).

It seems reasonable that ObjectBuilder should be able to read an encrypted config file; however I have been unable to dig up any mention of this as a capability.

Is this possible?

Thanks,

Kimball

CREATED ISSUE: Create objects through a static method call

yurik — Wed, 13 Feb 2008 17:38:17 GMT

There is a large number of libraries (including the framework itself), that uses a static method call on a factory class to create an instance of an object. I am in process of creating such strategy that will take a type, a method name, and a list of parameters, and use them to get a desired object.

COMMENTED ISSUE: Injecting COM objects throws an exception

yurik — Wed, 13 Feb 2008 17:33:16 GMT

Hi Guys,

ObjectBuilding my way through the visual studio IDE I ran into a problem when injecting Com-objects (such as the realization EnvDTE.DTE).

problem occurs when creating an object that gets an COM-object injected in its constructor.

Problem boils down to the Guard.TypeIsAssignableFromType throwing an exception if the found type is not assignablable from the constructor-paramters type.

if (!assignee.IsAssignableFrom(providedType))
throw new IncompatibleTypesException(....);

My workaround (the quickest, problably not the best -but here to provide insight on the issue)

if (!providedType.IsCOMObject)
if (!assignee.IsAssignableFrom(providedType))
throw new IncompatibleTypesException(....);
Comments: ** Comment from web user: yurik **

I ran into a similar problem, but with remoting objects. My solution was to add
&& providedType != typeof(MarshalByRefObject)
to the Guard.TypeIsAssignableFromType(), which solved it for any objects created through remoting.

NEW POST: DI and Object Builder Presentation & Source

burhan_Saadi — Wed, 13 Feb 2008 06:23:25 GMT

I have some Dependency Injection and Object Material (Presentation and Source Code) available on my blog. It may be useful for beginners to intermediate level. There are about 16+ basic poc's to get started with Object builder and Codeplex container. You can find these goods at http://burhansaadi.spaces.live.com/ and may help me to improve it further.
Burhan!