What would you like in OB 2.0?

Jul 18, 2006 at 5:13 PM

I would like to take this opportunity to ask what features the community would like to see in the next major version of ObjectBuilder.

Feel free to post here for discussion, or you can directly add the feature request to the Issue Tracker.

Aug 10, 2006 at 5:57 PM
I think the big request has been the need to have a Spring like configurable system to construct and inject object and values. Along this same thread would be a tool to create the config file (a schema to be used within VS would suffice as a start).
Aug 31, 2006 at 12:51 AM
I'm so impressed with the design of OB, I would hate to start programming in XML. I'm sure a more formal DI framework is around the corner...
Sep 5, 2006 at 12:14 PM
Better documentation (it's nearly non-existing now). Both good API docs and a set of samples to play with.


Lars Wilhelmsen
Senior Software Engineer
Teleplan Globe AS
Sep 6, 2006 at 1:13 AM
Not to sure but the ability to define an existing object that is not updated as part of the build-up but rather used as a starting template.

I'd also like to second the xml config for definig the container set-up. Would really help in testing scenarios.
Oct 5, 2006 at 3:44 PM
As the stated purpose of the ObjectBuilder is to be a framework for building DI containers, not to be a DI container itself, I would not like to see evolve into something that consumes config files, etc. so please ignore all requests along those lines :)

I would like to see the PropertySetterStrategy changed to allow properties to be set based on the object's equivalency to the policy type rather than just the specific type. For example, if I'm building an object and would like all objects which have a "ConfigurationSource" property to be set, I might want the policy type to just be of typeof(object). Please advise if there is another way of achieving this.

Another thing that might be considered is transient strategies. I have a Facade class similiar to the EnterpriseLibraryFactory class which allows people to use ObjectBuilder without all the setup. The problem is that in some cases people may want to use my default setup, but also provide their own Strategies without adding to the overhead of the main builder. Right now I'm achieving this by having my Facade class return a similarly constructed ObjectBuilder so the user can further customize, but this wouldn't be necessary if I could pass in a transient strategy. Please advise if there is a better way of achieving this.

Derek Greer

Oct 6, 2006 at 4:18 PM
Transient strategies would seem like a good addition. :)
Oct 12, 2006 at 3:41 AM
An additional creation phase strategy (and related policy) that support creating objects from static or instance factories instead of using a constructor of the object itself. Useful to wire in object creation for objects that require an external factory that the developer doesn't control.
Nov 13, 2006 at 3:14 PM
Whats missing is an object validation framework. so additionally to set the value, you can also validate it.

i written something like that for my asp.net site.
so in an aspx page i add an Public property and add an QueryString attribute that gets the value from the querystrings.
and also i implemented an setter, if the value isnt present (ifNotExist - the querystring not extist, ifConverstionFails - type converstion fails ( e.g. string->int)
and validation of these strings.
so i can add an additional
RangeValidatior(1,100) to it. and these were hard to add in the dependency framework. would be great to support such validation directly.
so bevore the value is set, the value is validated.
Nov 21, 2006 at 5:39 PM
Here are a few things, I'd like to see:

a) I'd like to see support for a less invasive method, which does not rely on attributes. I'm not asking that the use of Attributes be discontinued, but it should be an option and not a requirement.

b) I know it is said that OB is a framework for building DI container; but while we're at it, why not build a reference container as part of the offering that captures the most common scenarios? I don't think people should be building different containers for each and every project they do. Use the reference container, and if you need some special feature, then you have the full power of the underlying OB framework to change/subclass and provide this custom functionality.

c) I think it is very rude, to dismiss the use of XML DI bindings as some have suggested in their posts. This should be another option: You should have the freedom to choose to do it in code, as well by XML or any other means--to make it flexible. Those who have hang-ups about using XML, grow-up,and choose another profession! Part of what makes software development so exciting is that it is not static-new methods are always emerging. Just look at the new mechanisms in .NET 3.0-there's a lot of XML in there.

d) Thinking out loud, we can perhaps have an XML config method (as an extension to (c)) and build a configuration front-end to configure the DI. The eventual objective of the XML is to make it toolable. The goal is to improve productivity, and remove the need to have to learn some XML schema/options, etc.

e) Option for Auto wiring (by reflection or some other method) as well as explicit DI wiring.

I think OB has a lot of promise, but you have to listen to the community and take a broader approach, rather than a more narrowing one. This will encourage adoption of the framework, which will improve it. Those who don't like the reference container, they can continue to build their own with the underlying OB infrastructure. Those who don't like XML, they can have the freedom to do without it--everbody is happy:)

Nov 21, 2006 at 5:44 PM

BTW, in the XML config option, it should be flexible enough to read plain text config files, as well as XML config files embedded in the assembly.
Nov 21, 2006 at 9:38 PM
I don't think there's a "single" container, but I agree that purpose-built containers that people can use are very helpful.

Today, in the Samples directory, I have on-going work on the sample container that I've been using for talks and demos. I'm currently in the process of writing a CAB-less event broker for this container, among other things. I (along with the other committers) want to use this area as a "testing ground" for things that might end up as part of ObjectBuilder 2.0.
Dec 23, 2006 at 7:14 PM
Hi Brad!

As you know we really love CAB, OB and SCBAT at Algo. We have a very impressive Smart Client for the banking industry that would not have been possible w/o it. But in general, we are having pretty significant performance problems with OB, particuarly at startup. There is of course some perf hits to be expected due to OB's reflective nature but this is fairly large. I know I am talking without numbers but I know, in conversations with you, that you guys know about this and wanted to do something in 2.0. Is there anything you can do in general and are there some guidelines that we might look at?

Here is Steve's post: http://steve.emxsoftware.com/SmartClients/IncreasetheperformanceofCABand+ObjectBuilder
Will the the CabGen and ObGen tools that are available in the latest drop of the Mobile Client Software Factory help?

Here is my post: http://codebetter.com/blogs/sam.gentile/archive/2006/12/15/Where-We-are-Going-with-CAB-and-CAB2F00OB-Performance-2800Lack-of2900.aspx

Thanks in advance! Sorry for being vague but I wanted to get something started and then get you numbers after the holidays. Happy Holidays!
Dec 24, 2006 at 5:53 AM
I definitely think that there is an opportunity to extract everything that is currently tied to a framework but doesn't need to be (like EventBroker or the mobile CAB's perf enhancement tools).
Dec 28, 2006 at 2:59 PM
I would agree with the performance-related improvements that others have suggested. One straightforward way of improving performance would be to avoid re-analyzing types after they have already been created. Barring that, at least some sort of reflection cache would dramatically improve the system's efficiency.

Also, more documentation! :)
Jan 17, 2007 at 4:34 PM
I would love to see the following, many of which have been mentioned already:

1) Documentation.
2) Samples / Quickstarts
3) DI Container
4) Performance Improvements

I think 1, 2, and 4 speak for themselves.

I don't understand why people would argue against having a DI Container. I understand that OB is meant to provide a framework to build DI Containers, etc., but a DI container would allow people to better understand and use OB. Maybe it is a separate CodePlex workspace, but I think it is important and fills a need.

Those not wanting a DI container can just ignore it :) It wouldn't be a requirement to use.


Jan 17, 2007 at 5:22 PM

Thanks for the suggestions everybody. I'll feed these back into our process and we'll see what we can come up with.

Mar 15, 2007 at 1:31 AM
I'd like to have some implementation "details" changed:

  • Right now the CreationStrategy is not only creating but also registering the newly created object in the Locator. This means subsequent strategies cannot generate proxies (I'd love to get Castle DynamicProxy as a strategy ;-) and pass the proxy on to the rest of the pipeline. Separating out this registration from CreationStrategy and adding it as the last step in the pipeline would make this possible.

  • The way the CreateNew attribute works precludes using TypeMapper policies. Since CreateNew generates a guid ID for the newly created object, this ensures no unwanted Singleton policies are hit, but since it will not find any TypeMapper policies either, specifying CreateNew on a interface-typed property will cause an exception. Why shouldn't this be possible?

  • Most attributes are declared "sealed", which means I have to copy the DependencyAttribute most of the time, since many of my own attributes are specialiced DependencyAttributes.


Mar 16, 2007 at 3:22 AM

hpcd29 wrote:

c) I think it is very rude, to dismiss the use of XML DI bindings as some have suggested in their posts. This should be another option: You should have the freedom to choose to do it in code, as well by XML or any other means--to make it flexible.

I agree 100%. This is standard procedure with other DI containers and it's my only gripe with ObjectBuilder.

Our shop utlizes the CAB for our application, and we love it. But there comes a time when you would like to be able to inject different concrete versions of a particular type for different customers of your app. Without being able to do this through configuration, we're stuck with handling it through code, and that means factories and recompiles. When you see something like Windsor in action (courtesy of David Hayden's blog) if really makes you wish for the simplicity of configuration:

public class HomeController : SmartDispatcherController
    private IMyService _myService;
    public HomeController(IMyService myService)
        _myService = myService;
<?xml version="1.0" encoding="utf-8"?>
            service="HelloWorld.Model.IMyService, HelloWorld"
            type="HelloWorld.Model.MyService, HelloWorld" />

I see something like that and I see all sorts of potential for customizing my client's applications. We're halfway there already with CAB and modular Smartpart design. Being able to configure our dependencies through XML would take us the rest of the way.

Now, we understand ObjectBuilder is not a DI container by itself. We're working with the CAB WorkItem, which is the container built by the OB. And I assume there has to be a way to add configuration registration through XML by adding a policy or something. But there's only so many hours in a day. We're a small team; we're already up to our eyes with unit tests, acceptance tests, code, refactorings, customer feedback and bug/feature tracking. Learning ObjectBuilder so we can augment it just to add configuration capabilities seems like a lot of effort for something that should already be there (since it's already in other IoC containers).

Anyway, that would be my #1 request for version 2.0: some sort of configuration option (or documentation on how to produce this in our containers) so we don't have to register types through code all the time. If we could augment the CAB's WorkItem to handle types through configuration we'd be a happy group of campers.

Jan 12, 2008 at 5:04 AM
Hey Brad. One of the changes I'd like to see in the next version of Object Builder is to enable attributes to be aware of their containing objects. In the current implementation this would mean that the ParameterAttribute type would be passed a reference to the containing object when GetValue() is called. The reason for this is that there currently doesn't appear to be a way to vary the IoC behavior assigned to a given attribute based upon the composing type without creating a new reflection-based strategy. At times, this affects the ability to efficiently do full IoC.

As an example, consider the TraceSourceAttribute used within the CAB to facilitate the injection of a TraceSource instance. While the current method inverts the control of creating this dependency, the object is still required to specify what the name of the TraceSource will be. What I would consider to be "full" IoC in this case would be that an object would only declare that it needs a TraceSource, but wouldn't care whether it is given the same one every other type uses, one specific to its type, one based upon a logical association within a config file, etc. I presume the reason this wasn't done this way in the CAB was that attributes don't currently have a way to behave differently based upon who is using it. This means that if you want to use a DI approach that might work differently based upon the containing type then you would have to create a new Strategy that again reflected upon the properties looking for special attributes (thus my statement on the ability to do this being efficient). This would let you create a TraceSourceAttribute whose GetValue() returned a new TraceSource created with composingObject.GetType().FullName, fully removing all control from the dependent object.

If I am correct, this would also mean that the EventBrokerStrategy used by CAB wouldn't have to be a strategy, but could rather be attribute based. If I am incorrect about this limitation then please let me know.

Derek Greer
Jan 12, 2008 at 6:15 AM
I wanted to add a point of correction. I started examining this issue in the context of my TraceSource example which first lead me to conclude that the ReflectionStrategy would need to be changed. While this would satisfy the TraceSource example, after further thought the place to make such a change would probably be the PropertySetterStrategy since it is where the GetValue() is called (indirectly through the PropertySetterInfo.GetValue() ), and is where the containing object reference actually exists.

Derek Greer
Mar 23, 2008 at 11:13 PM
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.
Mar 24, 2008 at 2:56 AM
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.

Mar 24, 2008 at 3:08 AM
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.

Mar 24, 2008 at 4:03 PM

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)

Dec 25, 2008 at 4:49 PM
i totally agree with 'hpcd29' and the stuff he/she requested.
i see attributes to not be productive at all
Dec 25, 2008 at 5:37 PM
Edited Dec 25, 2008 at 5:45 PM
Update: I just realized someone else had suggested this. Pls ignore mine:

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.
Dec 28, 2009 at 7:39 PM

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.