Missing PolicyInjection.Create Method from PIAB

Topics: Policy Injection Application Block
Mar 4, 2007 at 12:59 AM
Edited Mar 4, 2007 at 1:01 AM
The PolicyInjection.Create Method I wanted to see is:

public static TInterface Create<TInterface>(params object[] args)

with the ability in the configuration file to map a particular class to an interface

  <service id="MyService" service="IService, IServiceAssembly" type="MyService, MyServiceAssembly" lifestyle="singleton" />

When I call:

IService service = PolicyInjection.Create<IService>();

I would like the PIAB to figure out the proper concrete service class.

Actually, the configuration piece is just a nice way to plug and play services without touching code. It would be nice if the PIAB had a container where I could register services manually, too.

The workaround now is to use my own container and then do a wrap.

TInterface = MyOwnFactory.Create<TInterface>();

where MyOwnFactory could be like:

public static MyOwnFactory {
   public static TInterface Create<TInterface>()
      object instance = GetServiceProvider<TInterface>();
      return PolicyInjection.WrapObject<TInterface>(instance);

Any chance of getting a simple container as part of the PIAB so I can avoid explicitly having to tell it the concrete class that implements the interface?




David Hayden
Microsoft MVP C#
Mar 4, 2007 at 10:29 PM
Hi Dave,

If I understand your scenario, you would be after a combination of DI and Injection.
This can be done using ObjectBuilder and the strategy and policy-pair designed for this scenario in the PolicyInjection assembly.

There is no out of the box configuration support or container (atleast for now) but from your example this should be fairly easy to implement using ObjectBuilder and its Singleton, TypeMapping and PolicyInjection- strategies.
Mar 5, 2007 at 4:52 PM

You're right :) I am looking for a DI container built on top of ObjectBuilder but nobody seems to want to give me one - neither the ObjectBuilder Project nor the Enterprise Library Project :(

Right now I am using Castle Windsor, which is great, but means I have a DI Container and Microkernelalongside all my Enterprise Library assemblies that use ObjectBuilder as a Dependency Injection Framework.

Then, of course, the software factories need containers so they build their own using Object Builder, such as that in the Composite Web Application Block for registering local and global services.

Now with the PIAB it has just gotten worse because I have to specify the actual class along with its interface to get wrapped. In my case, this means I have to grab the class from Castle Windsor and then wrap it up. And, if the software factories don't take to Enterprise Library 3.0 right away, it means I will have to do a similar approach with them.

We need to get a Dependency Injection Application Block in Enterprise Library and have a hook into it using the Policy Injection Application Block to make all this even more transparent.

I can't even tell you how exciting that combination would be ( or maybe I just did ;)!




David Hayden
Microsoft MVP C#
Mar 5, 2007 at 7:03 PM
I agree with David on this subject, i dont know enough to make my own DIAB, but i know u guys have the knowledge to.


Have u planed a workshop like the websf-guys shall have next week? If u do, let me know in good time, i have a critical project in its finishing stage, so i could not attend this time, but i hope i have the time to attend next time.
Mar 6, 2007 at 7:20 AM
I agree with David and Benny. Please give us at least a quickstart for a simple DI container using ObjectBuilder.

Håkan Forss
Mar 6, 2007 at 3:15 PM
I too have been waiting from some sort of standard DI container to emerge from EntLib or more directly from Object Builder. I understand that I have the option of building my own using the framework provided by object builder. The other option is to consider Windsor; it provides additional features such as dynamic proxies, allowing aspect orientated programming. However, as David has mentioned its not particulary desirably to have a couple of DI frameworks to achieve what one could potentially do.
Unfortunately this quandary has been troubling me ever since I first laid eyes on Object Builder. I was hoping that before I had to embark on architecting a new application, this would of sorted itself out with an elegant solution. Alas.
Some sort of clear indication of the direction things are going in, could at least help my decision making.

Mar 7, 2007 at 3:30 AM
I always assumed that the ObjectBuilder Team would eventually provide a container at some point and was pretty happy with using Castle Windsor. I figured the container would be part of ObjectBuilder 2.0 actually.

However, the Policy Injection Application Block was a last minute great surprise by the Enterprise Library Team and after playing with it I realize it screams the need for a Dependency Injection Application Block ( DIAB ).

The Policy Injection Application Block is great by itself and its Wrap<>() methods are wonderful when you need more control over how one gets the concrete instances to wrap. That makes sense as we want the separation of concerns.

However, we also need the PIAB to integrate with a DIAB so that in one call we get everything. Of course the DIAB will be provider based as well, so I can use a DI tool built by the Enterprise Library Team that uses ObjectBuilder or I could use a Castle Windsor Provider, etc.

It feels like a mistake not to address the dependency injection piece and offer it at the same time as the Policy Injection Application Block. Waiting for this functionality in Enterprise Library 4.0 in March of 2008 is hard to swallow.

I am sensing from Ed's comments on one of my blog posts that DI won't be addressed in EntLib 3.0 and it saddens me:


I apologize if I am harping on this subject to death, but I think it will truly make a huge impact and be a huge win for EntLib 3.0.




David Hayden
Microsoft MVP C#
Mar 7, 2007 at 6:10 AM
Edited Mar 7, 2007 at 6:11 AM
There is a quick start type example for Object Builder from the P&P Summit last October:


Works great. I would like to see better documentation so that I could better understand why there can't be a single container shared by CAB, PIAB, EL and the P&P example.

--David Morris
Mar 7, 2007 at 2:29 PM
Thanks, David.

I have worked with that sample as well as pulled containers from the Composite Application Block and Composite Web Application Block. I also use 3rd party DI Tools.

As you mention in your message, however, the need is bigger than an example download. We need an Enterprise Library Dependency Injection Application Block that is more plug and play like the other blocks and can be used by the Policy Injection Application Block as well as all the other application blocks in the various software factories.

Again, I wouldn't be harping on this if I didn't think the PIAB needed it and the demand was there. Putting out the PIAB with no thought of DI integration ( not just the Wrap<>() ability ) and support and implementation for a Dependency Injection Application Block is a mistake in my opinion and a misread of customer demand. It may be March of 2008 before we see Enterprise Library 4.0 and that functionality.

I know Tom is hearing this loud and clear and I know they are up against a pretty quick deadline with a PIAB to finish, but I can personally wait a couple additional weeks for an April 2007 release if they need the extra time to sort this problem out. I think this is a big one.

If they just add the extension points now and come out with a DIAB not too long after the EntLib 3.0 release that is fine for me. I guess I am hooked on that idea of having one call to the PIAB that will locate my concrete class that implements my service and then either return it or a proxy class depending on if methods need to be intercepted based on any policies in my configuration. Seems like such a natural use of the PIAB that I can't understand why it isn't in there.

I, of course, would also want the ability to just use the DIAB without the PIAB just like the reverse is true.




David Hayden
Microsoft MVP C#
Mar 8, 2007 at 5:07 AM
Edited Mar 8, 2007 at 5:08 AM

I agree with what you are saying. It is possible that there is a well thought out plan but I am not privy to that plan. It would help if there was documentation that described how ObjectBuilder works and why a few similar containers are better than one.

My vote would be to not hold up a release for a feature (DIAB) that wasn't in scope but I also wouldn't drop in PIAB until it can be properly vetted. I would like to see some work done on the configuration and a move to base PIAB on a more complete and shared dependency container.

I wouldn't want to hold up PIAB for a year but I am not convinced based on a few line blog that the current PIAB implementation is the best fit. Specifically I question the need to implement a complex and resource intensive proxy when other containers generate a proxy that is lighter-weight and better fits the requirement(CGLIB for example). A 3.1 release for DIAB and PIAB cleanup makes sense to me.

--David Morris
Mar 14, 2007 at 11:13 PM
> Specifically I question the need to implement a complex and resource intensive proxy

The entire proxy code in PIAB is 152 lines long, including the comments. It's not complex; that's one of the reasons we went with this implementation. Also, one of the design goals was to allow users to use different interception mechanisms if they wanted to. We've heard about two such methods being used successfully already (one using ContextBoundObject, another using static IL merging).