ObjectBuilder Dependency Injection Framework

Closed Issue: n-deep Containers Not Supported [13636]

BradWilson — Thu, 16 May 2013 07:10:24 GMT

Trying to embed containers multiple levels deep doesn't work because staged strategy chain does not properly consult the parent strategy chain.

Closed Issue: Bug in ParametersToTypeList method of the BuilderStrategy class [14140]

BradWilson — Thu, 16 May 2013 07:10:23 GMT

I found a bug in the ParametersToTypeList method of the BuilderStrategy class. Inside the method it execute "parameter.GetType().Name". This does not take into account that "parameter" can be null, causing a exeception. This bug was exposed when I used a SCSF service with a constructor as follows:

MyService([ServiceDependency] IOtherService s1, [ServiceDependency(Required=false)] IAnotherService s2)

The second parameter is not required and can thus be null. These two parameters is eventually passed into the ParametersToTypeList function where the second entry in the array is null, causing the exception. The fix for the bug is as follows:

/// <summary>
/// Creates a trace list of parameter types from a list of <see cref="IParameter"/> objects.
/// </summary>
/// <param name="parameters">The parameters</param>
/// <returns>The type list in string form</returns>
protected string ParametersToTypeList(params object[] parameters)
{
List<string> types = new List<string>();

foreach (object parameter in parameters)
{
if (parameter != null)
types.Add(parameter.GetType().Name);
else
types.Add("null");
}

return string.Join(", ", types.ToArray());
}

Source code checked in, #99885

Project Collection Service Accounts — Mon, 01 Oct 2012 21:24:31 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #99884

Project Collection Service Accounts — Mon, 01 Oct 2012 21:16:08 GMT

Checked in by server upgrade

Reviewed: 1.0.51206.0 Production (十一月 15, 2011)

y_2222 — Wed, 16 Nov 2011 05:40:51 GMT

Rated 2 Stars (out of 5) - yes,I hope I can down it

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

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);

Source code checked in, #74794

_TFSSERVICE — Tue, 03 Aug 2010 19:44:57 GMT

Checked in by server upgrade

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: Builder Strategy Order

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

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

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

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.

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

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.

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: 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.

Reviewed: 1.0.51206.0 Production (Dec 15, 2009)

marten_range — Tue, 15 Dec 2009 20:54:37 GMT

Rated 5 Stars (out of 5) - ObjectBuilder is often the technical foundation of all projects I start. The simplicity and transparency of the design is one of the major benefits of ObjectBuilder over other DI framework/containers I've looked upon. Even though ObjectBuilder is dated it's still excellent. If nothing else it's a good example on excellent design.

Commented Issue: Using custom Parameter Attribute gives Key Not Found in Dictionary Exception

jatindua — Wed, 29 Apr 2009 00:42:50 GMT

Hi There,

We have developed our own custom attribute similiar to the CreateNew attribute in WCSF. We have called it CreateNewOnce so that within an HTTPContext, an object of a particular type is created just once, no matter how many times its property is accessed. I have attached the code below. Now, this worked perfectly in Microsoft.Practices.CompositeWeb.EnterpriseLibrary v 2.0.0.0 but in the new 3.5 version it gives a Key Not found Exception. I have pasted the exception below as well. Its almost as if the Object Builder is unaware of the CreateNewOnce attribute. Do we need to register it somewhere to let Object Builder know of its existance. I would have thought inherting from Parameter Attribute should do that for us. What has changed in the new Object Builder version?

Any help will be greatly apreciated. The code breaks at public CreateNewOnceAttribute() { }

Thanks Jatin

Error:
[KeyNotFoundException: The given key was not present in the dictionary.]

System.ThrowHelper.ThrowKeyNotFoundException() +28

System.Collections.Generic.Dictionary`2.get_Item(TKey key) +7452124

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.Parameters.ParameterResolverMap.GetResolver(ParameterAttribute resolutionAttribute) +77

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.Properties.SetPropertiesStrategy.EmitResolveProperty(ILGenerator il, PropertyInfo prop) +87

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.Properties.SetPropertiesStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild, ILGenerator il) +395

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.PlanBuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +105

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.PlanBuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +126

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.DynamicMethodPlanBuilderPolicy.CreatePlan(Type typeToBuild, String idToBuild) +372

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.BuildPlanStrategy.GetPlanFromContext(IBuilderContext context, Type typeToBuild, String idToBuild) +157

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.BuildPlanStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +51

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.CompositeWeb.ObjectBuilder.Strategies.SimplifiedSingletonStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +245

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.ObjectBuilder.TypeMappingStrategy.BuildUp(IBuilderContext context, Type t, Object existing, String id) +278

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.CompositeWeb.BuilderStrategies.ContainerAwareTypeMappingStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +255

BuildUp_ASP.modules_inbox_inbox_aspx(IBuilderContext , Type , Object , String ) +171

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.DynamicMethodPlan.DynamicMethodBuildPlan.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String id) +63

Microsoft.Practices.CompositeWeb.ObjectBuilder.BuildPlan.BuildPlanStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +81

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.CompositeWeb.ObjectBuilder.Strategies.SimplifiedSingletonStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +245

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.ObjectBuilder.TypeMappingStrategy.BuildUp(IBuilderContext context, Type t, Object existing, String id) +278

Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +38

Microsoft.Practices.CompositeWeb.BuilderStrategies.ContainerAwareTypeMappingStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild) +289

Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderBase`1.DoBuildUp(IReadWriteLocator locator, Type typeToBuild, String idToBuild, Object existing, PolicyList[] transientPolicies) +139

Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderBase`1.BuildUp(IReadWriteLocator locator, Type typeToBuild, String idToBuild, Object existing, PolicyList[] transientPolicies) +55

Microsoft.Practices.CompositeWeb.CompositionContainer.BuildItem(IBuilder`1 builder, IReadWriteLocator locator, Object item) +411

Microsoft.Practices.CompositeWeb.WebClientApplication.BuildItemWithCurrentContext(Object obj) +187

Microsoft.Practices.CompositeWeb.Web.UI.Page.OnPreInit(EventArgs e) +47

System.Web.UI.Page.PerformPreInit() +31

System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +282
Comments: ** Comment from web user: jatindua **

Sorry the Impact is High not Low...

Created Issue: Using custom Parameter Attribute gives Key Not Found in Dictionary Exception

jatindua — Wed, 29 Apr 2009 00:33:58 GMT

Reviewed: 1.0.51206.0 Production (Dec 27, 2008)

gsscoder — Sat, 27 Dec 2008 12:32:22 GMT

Rated 5 Stars (out of 5) - Abstraction, decoupling and flexible architectures are the future of software design.

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