ObjectBuilder Forum Rss Feed

New Post: Builder Strategy Order

gigiabbrescia — Thu, 14 Oct 2010 13:54:06 GMT

I have created the following strategy:

    public class TypeMappingStrategyWithoutPolicyId : BuilderStrategy
    {
        /// <summary>
        /// Implementation of <see cref="IBuilderStrategy.BuildUp"/>.
        /// </summary>
        public override object BuildUp(IBuilderContext context, Type t, object existing, string id)
        {
            DependencyResolutionLocatorKey result = new DependencyResolutionLocatorKey(t, id);

            ITypeMappingPolicy policy = context.Policies.Get<ITypeMappingPolicy>(t, null);

            if (policy != null)
            {
                result = policy.Map(result);
                TraceBuildUp(context, t, id, Properties.Resources.TypeMapped, result.Type, result.ID ?? "(null)");
                Guard.TypeIsAssignableFromType(t, result.Type, t);

                return context.HeadOfChain.BuildUp(context, result.Type, existing, id);
            }

            return base.BuildUp(context, result.Type, existing, id);
        }
    }

The instruction :

context.HeadOfChain.BuildUp(context, result.Type, existing, id);

reinsert the mapped type in ObjectBuilder "pipeline" resolving the dependency.

The policy for mapping is:

Builder.Policies.Set<ITypeMappingPolicy>(new TypeMappingPolicy(typeof(SplashView), null), typeof(ISplashView), null);

New Post: Builder Strategy Order

stephencampling — Mon, 24 May 2010 08:32:01 GMT

The Composite Application UI Block (CAB) uses Object Builder for dependency injection. I faced a problem when trying to unit test certain areas of CAB as they reference concrete implementations of views and services such as the following line of code;

ISplashView splashView = WorkItem.SmartParts.AddNew<SplashView>();

Object Builder is used to create and return an instance of the SplashView.

My approach was to create a new builder strategy for Object Builder that occurred at the stage of PreCreation. My strategy uses mappings between interfaces and concrete classes from the application configuration file in order to build the correct object – so my code now looks like the following;

ISplashView splashView = WorkItem.SmartParts.AddNew<ISplashView>();

The splash view can now be mocked and the class becomes unit testable and the assemblies less tightly coupled.

It all works fine apart from the property based dependency injection (which doesn’t work at all). Object Builder allows you to add several attributes to properties to allow them to be set by Object Builder, for example;

[CreateNew]
public SplashViewPresenter Presenter
{
    set
        {
              _presenter = value;
              _presenter.View = this;
         }
}

I'm aware that there is a strategy available out of the box called TypeMappingStrategy, however, the mapping is done in code so we still end up with non unit testable code. It also means we need to create a policy for each type we wish to build so it would be a reasonable amount of code.

From what I understand, there is a builder strategy that is responsible for setting these properties using reflection. This strategy is also in the PreCreation stage.

I think that the reason its not working with my strategy is down to the order that the strategies are executed. Mine would have to be the first one to run as it is essentially changing the type that we are trying to build. If the strategy responsible for setting the properties ran before mine, it would be running on the interface and not the concrete class.

If that assumption is true then the simple fix would be to re-order the strategies to ensure that mine was the first to run, however, I can’t find a way to do it.

Cheers
Steve.

New Post: Is ObjectBuilder dead?

michaelsync — Wed, 03 Feb 2010 07:54:17 GMT

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

I think Chris already integrated ObjectBuilder into Unity so Unity can run without OB dll. Does it means OB is dead now?

New Post: What would you like in OB 2.0?

abombss — Mon, 28 Dec 2009 19:39:08 GMT

I would like to see performance improvements with the PolicyList.Set; I think it has been changed copy the policy dictionary to prevent multi-threading issues so locks don't need to be carried around. This has killed performance in our application when using Unity IoC and resolving components which are not singletons. While the copy took a lot of time, an even bigger issue was the pressure put on the GC. When we optimized our code to use unity to resolve the whole dependency chain, we cut our PolicyList.Set calls down by a factor of 3, there were 3 dependencies in the chain. This not only cut resolution time down it cut our %GC time from 30% to 0.5%. That alone was one of the biggest saving graces.

New Post: What would you like in OB 2.0?

jeffsaremi — Thu, 25 Dec 2008 17:37:32 GMT

Update: I just realized someone else had suggested this. Pls ignore mine:
http://www.codeplex.com/ObjectBuilder/Thread/View.aspx?ThreadId=2256

Here's something I could think of. I apologize if ultimately some or all of this may be irrelevant due to the fact that I'm just getting my feet wet with this framework.
This enhancement relates to ReflectionStrategy and its derivatives.
It would be nice if after a Type is reflected for its contracutors/methods/properties that need some sort of injection, this information be cached. By that i don't mean the object but rather the type's injection points. The next object to be built from the same type would not have be wait for the whole reflection to take place again.
jeff

New Post: The Contrast between "object existing" and BuilderStage.PreCreation

jeffsaremi — Thu, 25 Dec 2008 17:25:40 GMT

Before the creation of an object that is the BuilderStag.PreCreation, what is it that is being passed as "existing" in the BuildUp method? Are we supposed to have an object before it's being created? What sort of object is that?
thanks
jeff

New Post: What Does SingletonStrategy do?

jeffsaremi — Thu, 25 Dec 2008 17:22:11 GMT

If someone could direct me to any material explaining what SingletonStrategy does and why it's needed I'd appreciate it.
It looks like that CreationStrategy already handles Singletons.
thanks
jeff

New Post: Why is OB not DI container but a "framework"?

jeffsaremi — Thu, 25 Dec 2008 16:52:00 GMT

i dont know either but this article explains well what the OB is:
http://www.tavaresstudios.com/Blog/post/Deconstructing-ObjectBuilder-What-Is-ObjectBuilder.aspx

New Post: What would you like in OB 2.0?

jeffsaremi — Thu, 25 Dec 2008 16:49:00 GMT

i totally agree with 'hpcd29' and the stuff he/she requested.
i see attributes to not be productive at all

New Post: Does anyone use Microsoft.Practices.ObjectBuilder2 standalone?

ctavares — Mon, 10 Nov 2008 17:59:05 GMT

Hey folks. Quick question for you: is anyone in the OB community using the p&p version of OB2 that ships with the Unity container & entlib 4? Right now, I don't know of any, and if nobody is I'm going to merge the OB2 and Unity assemblies to simplify deployment. Would this cause heartburn for anyone?

Thanks,

-Chris

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.