Wrapper for IOC functions

[Tariq Hassanen-2]

Hi all,

I've been testing several IOC frameworks now and there are alot that seem to
suit most scenarios.

I've been bitten in the past for choosing a particular implementation (such
as logging) without implementing a wrapper for it, so that when it came to
swap it out for another implementation it was a nightmare to do so.

I was wondering is there a way to wrap an IOC implementation so I dont have
the same nightmare in the future?
Is there already an IOC wrapper out there that covers 90% of the common
functionality?

Tariq

[Chris Brandsma]

You want the Common Service Locator:

http://commonservicelocator.codeplex.com/

But realistically, most of your code (90% or more) should not know that you
are using an IoC.

On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen <tariq.hassanen@...>wrote:

>
>
> Hi all,
>
> I've been testing several IOC frameworks now and there are alot that seem
> to suit most scenarios.
>
> I've been bitten in the past for choosing a particular implementation (such
> as logging) without implementing a wrapper for it, so that when it came to
> swap it out for another implementation it was a nightmare to do so.
>
> I was wondering is there a way to wrap an IOC implementation so I dont have
> the same nightmare in the future?
> Is there already an IOC wrapper out there that covers 90% of the common
> functionality?
>
> Tariq
>  
>

--
--------------------------------
Christopher Brandsma
http://www.ChrisBrandsma.com
http://www.ElegantCode.com

[Glenn Block-2]

CSL is not meant to be the uber abstraction / ioc. We designed it only
for resolution and not registration. It is there primarily for
frameworks that want to be IoC independent and is meant for low-level
components.

The problem is that you end up in the least common denominator to have
such an interface. Every container has it's own unique features and
they all tend to work differently. I'd recommend just choosing an IoC
that works for you rather than creating some general wrapper.

There is a project called MetaContainer on Codeplex though which
provides the generic container abstraction you are looking for.

Regards
Glenn



On 11/6/09, Chris Brandsma <chris.brandsma@...> wrote:

> You want the Common Service Locator:
>
> http://commonservicelocator.codeplex.com/
>
> But realistically, most of your code (90% or more) should not know that you
> are using an IoC.
>
> On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> <tariq.hassanen@...>wrote:
>
>>
>>
>> Hi all,
>>
>> I've been testing several IOC frameworks now and there are alot that seem
>> to suit most scenarios.
>>
>> I've been bitten in the past for choosing a particular implementation
>> (such
>> as logging) without implementing a wrapper for it, so that when it came to
>> swap it out for another implementation it was a nightmare to do so.
>>
>> I was wondering is there a way to wrap an IOC implementation so I dont
>> have
>> the same nightmare in the future?
>> Is there already an IOC wrapper out there that covers 90% of the common
>> functionality?
>>
>> Tariq
>>
>>
>
>
>
> --
> --------------------------------
> Christopher Brandsma
> http://www.ChrisBrandsma.com
> http://www.ElegantCode.com
>

--
Sent from my mobile device

[Mark Seemann]

You shouldn't need a wrapper, since you should rather strive to make all your code DI Container-agnostic.

Contrary to the use of a Service Locator (an anti-pattern if you ask me), DI can be implemented by using simple patterns such as Constructor Injection. None of your classes that have dependencies need to reference any particular DI Container - they can just use their constructors to publish what they need. Any DI Container will be able to auto-wire an application and then get out of the way.

It is only at the Composition Root that a DI Container should come into play, and that is one very isolated place where you can easily replace one DI Container with another, so just pick one you like and use it like that.

Mark Seemann
http://blog.ploeh.dk<http://blog.ploeh.dk/>
Twitter: ploeh
([phone]

Dependency Injection in .NET<http://www.manning.com/seemann/>

From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Glenn Block
Sent: 7. november 2009 04:12
To: altdotnet@...
Subject: Re: [altdotnet] Wrapper for IOC functions



CSL is not meant to be the uber abstraction / ioc. We designed it only
for resolution and not registration. It is there primarily for
frameworks that want to be IoC independent and is meant for low-level
components.

The problem is that you end up in the least common denominator to have
such an interface. Every container has it's own unique features and
they all tend to work differently. I'd recommend just choosing an IoC
that works for you rather than creating some general wrapper.

There is a project called MetaContainer on Codeplex though which
provides the generic container abstraction you are looking for.

Regards
Glenn

On 11/6/09, Chris Brandsma <chris.brandsma@...<mailto:chris.brandsma%40gmail.com>> wrote:

> You want the Common Service Locator:
>
> http://commonservicelocator.codeplex.com/
>
> But realistically, most of your code (90% or more) should not know that you
> are using an IoC.
>
> On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> <tariq.hassanen@...<mailto:tariq.hassanen%40gmail.com>>wrote:
>
>>
>>
>> Hi all,
>>
>> I've been testing several IOC frameworks now and there are alot that seem
>> to suit most scenarios.
>>
>> I've been bitten in the past for choosing a particular implementation
>> (such
>> as logging) without implementing a wrapper for it, so that when it came to
>> swap it out for another implementation it was a nightmare to do so.
>>
>> I was wondering is there a way to wrap an IOC implementation so I dont
>> have
>> the same nightmare in the future?
>> Is there already an IOC wrapper out there that covers 90% of the common
>> functionality?
>>
>> Tariq
>>
>>
>
>
>
> --
> --------------------------------
> Christopher Brandsma
> http://www.ChrisBrandsma.com
> http://www.ElegantCode.com
>

--
Sent from my mobile device

[Mark Seemann]

In other words; the Hollywood Principle applies: Don't call your DI Container - it'll call you.

Mark Seemann
http://blog.ploeh.dk<http://blog.ploeh.dk/>
Twitter: ploeh
([phone]

Dependency Injection in .NET<http://www.manning.com/seemann/>

From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Mark Seemann
Sent: 7. november 2009 09:58
To: altdotnet@...
Subject: RE: [altdotnet] Wrapper for IOC functions


You shouldn't need a wrapper, since you should rather strive to make all your code DI Container-agnostic.

Contrary to the use of a Service Locator (an anti-pattern if you ask me), DI can be implemented by using simple patterns such as Constructor Injection. None of your classes that have dependencies need to reference any particular DI Container - they can just use their constructors to publish what they need. Any DI Container will be able to auto-wire an application and then get out of the way.

It is only at the Composition Root that a DI Container should come into play, and that is one very isolated place where you can easily replace one DI Container with another, so just pick one you like and use it like that.

Mark Seemann
http://blog.ploeh.dk<http://blog.ploeh.dk/>
Twitter: ploeh
([phone]

Dependency Injection in .NET<http://www.manning.com/seemann/>

From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Glenn Block
Sent: 7. november 2009 04:12
To: altdotnet@...
Subject: Re: [altdotnet] Wrapper for IOC functions



CSL is not meant to be the uber abstraction / ioc. We designed it only
for resolution and not registration. It is there primarily for
frameworks that want to be IoC independent and is meant for low-level
components.

The problem is that you end up in the least common denominator to have
such an interface. Every container has it's own unique features and
they all tend to work differently. I'd recommend just choosing an IoC
that works for you rather than creating some general wrapper.

There is a project called MetaContainer on Codeplex though which
provides the generic container abstraction you are looking for.

Regards
Glenn

On 11/6/09, Chris Brandsma <chris.brandsma@...<mailto:chris.brandsma%40gmail.com>> wrote:

> You want the Common Service Locator:
>
> http://commonservicelocator.codeplex.com/
>
> But realistically, most of your code (90% or more) should not know that you
> are using an IoC.
>
> On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> <tariq.hassanen@...<mailto:tariq.hassanen%40gmail.com>>wrote:
>
>>
>>
>> Hi all,
>>
>> I've been testing several IOC frameworks now and there are alot that seem
>> to suit most scenarios.
>>
>> I've been bitten in the past for choosing a particular implementation
>> (such
>> as logging) without implementing a wrapper for it, so that when it came to
>> swap it out for another implementation it was a nightmare to do so.
>>
>> I was wondering is there a way to wrap an IOC implementation so I dont
>> have
>> the same nightmare in the future?
>> Is there already an IOC wrapper out there that covers 90% of the common
>> functionality?
>>
>> Tariq
>>
>>
>
>
>
> --
> --------------------------------
> Christopher Brandsma
> http://www.ChrisBrandsma.com
> http://www.ElegantCode.com
>

--
Sent from my mobile device

[patrik.hagne-2]

I totally agree with this, and I had to learn this the hard way, starting out using what's now considered an antipattern (static service locator) and moving on to using constructor injection and "injeted context". This keeps you IoC-container only at the infrastructure level and your code never has to know about it.

Nicholas Blumhardt, the author of my favourite container Autofac wrote a couple of posts on this subject a year or so ago that starts with this post:

http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx

Does anyone know of any good "example implementation" of this pattern that could guid "newbies"? I think that it's very easy to fall into the static service locator pit unless you have some guidance.

/Patrik

--- In altdotnet@..., Mark Seemann <mark@...> wrote:

>
> You shouldn't need a wrapper, since you should rather strive to make all your code DI Container-agnostic.
>
> Contrary to the use of a Service Locator (an anti-pattern if you ask me), DI can be implemented by using simple patterns such as Constructor Injection. None of your classes that have dependencies need to reference any particular DI Container - they can just use their constructors to publish what they need. Any DI Container will be able to auto-wire an application and then get out of the way.
>
> It is only at the Composition Root that a DI Container should come into play, and that is one very isolated place where you can easily replace one DI Container with another, so just pick one you like and use it like that.
>
> Mark Seemann
> http://blog.ploeh.dk<http://blog.ploeh.dk/>
> Twitter: ploeh
> ([phone]
>
> Dependency Injection in .NET<http://www.manning.com/seemann/>
>
> From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Glenn Block
> Sent: 7. november 2009 04:12
> To: altdotnet@...
> Subject: Re: [altdotnet] Wrapper for IOC functions
>
>
>
> CSL is not meant to be the uber abstraction / ioc. We designed it only
> for resolution and not registration. It is there primarily for
> frameworks that want to be IoC independent and is meant for low-level
> components.
>
> The problem is that you end up in the least common denominator to have
> such an interface. Every container has it's own unique features and
> they all tend to work differently. I'd recommend just choosing an IoC
> that works for you rather than creating some general wrapper.
>
> There is a project called MetaContainer on Codeplex though which
> provides the generic container abstraction you are looking for.
>
> Regards
> Glenn
>
> On 11/6/09, Chris Brandsma <chris.brandsma@...<mailto:chris.brandsma%40gmail.com>> wrote:
> > You want the Common Service Locator:
> >
> > http://commonservicelocator.codeplex.com/
> >
> > But realistically, most of your code (90% or more) should not know that you
> > are using an IoC.
> >
> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> > <tariq.hassanen@...<mailto:tariq.hassanen%40gmail.com>>wrote:
> >
> >>
> >>
> >> Hi all,
> >>
> >> I've been testing several IOC frameworks now and there are alot that seem
> >> to suit most scenarios.
> >>
> >> I've been bitten in the past for choosing a particular implementation
> >> (such
> >> as logging) without implementing a wrapper for it, so that when it came to
> >> swap it out for another implementation it was a nightmare to do so.
> >>
> >> I was wondering is there a way to wrap an IOC implementation so I dont
> >> have
> >> the same nightmare in the future?
> >> Is there already an IOC wrapper out there that covers 90% of the common
> >> functionality?
> >>
> >> Tariq
> >>
> >>
> >
> >
> >
> > --
> > --------------------------------
> > Christopher Brandsma
> > http://www.ChrisBrandsma.com
> > http://www.ElegantCode.com
> >
>
> --
> Sent from my mobile device
>

[Morten Maxild]

+1

 

Nice

 

  _____  

From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Mark Seemann
Sent: Saturday, November 07, 2009 9:58 AM
To: altdotnet@...
Subject: RE: [altdotnet] Wrapper for IOC functions

 

 

You shouldn't need a wrapper, since you should rather strive to make all your code DI Container-agnostic.

 

Contrary to the use of a Service Locator (an anti-pattern if you ask me), DI can be implemented by using simple patterns such as Constructor Injection. None of your classes that have dependencies need to reference any particular DI Container - they can just use their constructors to publish what they need. Any DI Container will be able to auto-wire an application and then get out of the way.

 

It is only at the Composition Root that a DI Container should come into play, and that is one very isolated place where you can easily replace one DI Container with another, so just pick one you like and use it like that.

 

Mark Seemann

 <http://blog.ploeh.dk/> http://blog.ploeh.dk

Twitter: ploeh

([phone]

 

Dependency Injection <http://www.manning.com/seemann/>  in .NET

 

From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Glenn Block
Sent: 7. november 2009 04:12
To: altdotnet@...
Subject: Re: [altdotnet] Wrapper for IOC functions

 

 

CSL is not meant to be the uber abstraction / ioc. We designed it only
for resolution and not registration. It is there primarily for
frameworks that want to be IoC independent and is meant for low-level
components.

The problem is that you end up in the least common denominator to have
such an interface. Every container has it's own unique features and
they all tend to work differently. I'd recommend just choosing an IoC
that works for you rather than creating some general wrapper.

There is a project called MetaContainer on Codeplex though which
provides the generic container abstraction you are looking for.

Regards
Glenn

On 11/6/09, Chris Brandsma <chris.brandsma@ <mailto:chris.brandsma%40gmail.com> gmail.com> wrote:

> You want the Common Service Locator:
>
> http://commonservic <http://commonservicelocator.codeplex.com/> elocator.codeplex.com/
>
> But realistically, most of your code (90% or more) should not know that you
> are using an IoC.
>
> On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> <tariq.hassanen@ <mailto:tariq.hassanen%40gmail.com> gmail.com>wrote:
>
>>
>>
>> Hi all,
>>
>> I've been testing several IOC frameworks now and there are alot that seem
>> to suit most scenarios.
>>
>> I've been bitten in the past for choosing a particular implementation
>> (such
>> as logging) without implementing a wrapper for it, so that when it came to
>> swap it out for another implementation it was a nightmare to do so.
>>
>> I was wondering is there a way to wrap an IOC implementation so I dont
>> have
>> the same nightmare in the future?
>> Is there already an IOC wrapper out there that covers 90% of the common
>> functionality?
>>
>> Tariq
>>
>>
>
>
>
> --
> --------------------------------
> Christopher Brandsma
> http://www.ChrisBra <http://www.ChrisBrandsma.com> ndsma.com
> http://www.ElegantC <http://www.ElegantCode.com> ode.com
>

--
Sent from my mobile device

[Glenn Block-2]

In MEF, we (Nick drove this) introduced a concept called
PartCreator<T>  which is essentially a generic factory that a
component takes a dependency. PartCreator allows components to spin up
new instances without having to be exposed to the container.

You can create something simlar through a  Factory<T>. The factory
wraps a container and delegates calls to it.

The factory is only used for cases where dynamic insantiation is needed.

If you check Nick's blog you will see a post on this.

On 11/7/09, Patrik <patrik@...> wrote:

> I totally agree with this, and I had to learn this the hard way, starting
> out using what's now considered an antipattern (static service locator) and
> moving on to using constructor injection and "injeted context". This keeps
> you IoC-container only at the infrastructure level and your code never has
> to know about it.
>
> Nicholas Blumhardt, the author of my favourite container Autofac wrote a
> couple of posts on this subject a year or so ago that starts with this post:
>
> http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
>
> Does anyone know of any good "example implementation" of this pattern that
> could guid "newbies"? I think that it's very easy to fall into the static
> service locator pit unless you have some guidance.
>
> /Patrik
>
> --- In altdotnet@..., Mark Seemann <mark@...> wrote:
>>
>> You shouldn't need a wrapper, since you should rather strive to make all
>> your code DI Container-agnostic.
>>
>> Contrary to the use of a Service Locator (an anti-pattern if you ask me),
>> DI can be implemented by using simple patterns such as Constructor
>> Injection. None of your classes that have dependencies need to reference
>> any particular DI Container - they can just use their constructors to
>> publish what they need. Any DI Container will be able to auto-wire an
>> application and then get out of the way.
>>
>> It is only at the Composition Root that a DI Container should come into
>> play, and that is one very isolated place where you can easily replace one
>> DI Container with another, so just pick one you like and use it like that.
>>
>> Mark Seemann
>> http://blog.ploeh.dk<http://blog.ploeh.dk/>
>> Twitter: ploeh
>> ([phone]
>>
>> Dependency Injection in .NET<http://www.manning.com/seemann/>
>>
>> From: altdotnet@... [mailto:altdotnet@...] On
>> Behalf Of Glenn Block
>> Sent: 7. november 2009 04:12
>> To: altdotnet@...
>> Subject: Re: [altdotnet] Wrapper for IOC functions
>>
>>
>>
>> CSL is not meant to be the uber abstraction / ioc. We designed it only
>> for resolution and not registration. It is there primarily for
>> frameworks that want to be IoC independent and is meant for low-level
>> components.
>>
>> The problem is that you end up in the least common denominator to have
>> such an interface. Every container has it's own unique features and
>> they all tend to work differently. I'd recommend just choosing an IoC
>> that works for you rather than creating some general wrapper.
>>
>> There is a project called MetaContainer on Codeplex though which
>> provides the generic container abstraction you are looking for.
>>
>> Regards
>> Glenn
>>
>> On 11/6/09, Chris Brandsma
>> <chris.brandsma@...<mailto:chris.brandsma%40gmail.com>> wrote:
>> > You want the Common Service Locator:
>> >
>> > http://commonservicelocator.codeplex.com/
>> >
>> > But realistically, most of your code (90% or more) should not know that
>> > you
>> > are using an IoC.
>> >
>> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
>> > <tariq.hassanen@...<mailto:tariq.hassanen%40gmail.com>>wrote:
>> >
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I've been testing several IOC frameworks now and there are alot that
>> >> seem
>> >> to suit most scenarios.
>> >>
>> >> I've been bitten in the past for choosing a particular implementation
>> >> (such
>> >> as logging) without implementing a wrapper for it, so that when it came
>> >> to
>> >> swap it out for another implementation it was a nightmare to do so.
>> >>
>> >> I was wondering is there a way to wrap an IOC implementation so I dont
>> >> have
>> >> the same nightmare in the future?
>> >> Is there already an IOC wrapper out there that covers 90% of the common
>> >> functionality?
>> >>
>> >> Tariq
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > --------------------------------
>> > Christopher Brandsma
>> > http://www.ChrisBrandsma.com
>> > http://www.ElegantCode.com
>> >
>>
>> --
>> Sent from my mobile device
>>
>
>
>

--
Sent from my mobile device

[patrik.hagne-2]

Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast you did, can't remember which) but to me this ties you tighter to the IoC-specific implementation. The IoC in this case being MEF (don't shoot me for calling it an IoC). You can achieve the same thing by injecting some domain specific factory that just wraps the container. The way to do this in Autofac for example is through generated factories. The philosophy is pretty much the same though.

As I said this is drawn from my quite shallow understanding of PartCreator<T> since I haven't taken a closer look at it since the web cast.

Cheers mate,
Patrik

--- In altdotnet@..., Glenn Block <glenn.block@...> wrote:

>
> In MEF, we (Nick drove this) introduced a concept called
> PartCreator<T>  which is essentially a generic factory that a
> component takes a dependency. PartCreator allows components to spin up
> new instances without having to be exposed to the container.
>
> You can create something simlar through a  Factory<T>. The factory
> wraps a container and delegates calls to it.
>
> The factory is only used for cases where dynamic insantiation is needed.
>
> If you check Nick's blog you will see a post on this.
>
> On 11/7/09, Patrik <patrik@...> wrote:
> > I totally agree with this, and I had to learn this the hard way, starting
> > out using what's now considered an antipattern (static service locator) and
> > moving on to using constructor injection and "injeted context". This keeps
> > you IoC-container only at the infrastructure level and your code never has
> > to know about it.
> >
> > Nicholas Blumhardt, the author of my favourite container Autofac wrote a
> > couple of posts on this subject a year or so ago that starts with this post:
> >
> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
> >
> > Does anyone know of any good "example implementation" of this pattern that
> > could guid "newbies"? I think that it's very easy to fall into the static
> > service locator pit unless you have some guidance.
> >
> > /Patrik
> >
> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
> >>
> >> You shouldn't need a wrapper, since you should rather strive to make all
> >> your code DI Container-agnostic.
> >>
> >> Contrary to the use of a Service Locator (an anti-pattern if you ask me),
> >> DI can be implemented by using simple patterns such as Constructor
> >> Injection. None of your classes that have dependencies need to reference
> >> any particular DI Container - they can just use their constructors to
> >> publish what they need. Any DI Container will be able to auto-wire an
> >> application and then get out of the way.
> >>
> >> It is only at the Composition Root that a DI Container should come into
> >> play, and that is one very isolated place where you can easily replace one
> >> DI Container with another, so just pick one you like and use it like that.
> >>
> >> Mark Seemann
> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
> >> Twitter: ploeh
> >> ([phone]
> >>
> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
> >>
> >> From: altdotnet@... [mailto:altdotnet@...] On
> >> Behalf Of Glenn Block
> >> Sent: 7. november 2009 04:12
> >> To: altdotnet@...
> >> Subject: Re: [altdotnet] Wrapper for IOC functions
> >>
> >>
> >>
> >> CSL is not meant to be the uber abstraction / ioc. We designed it only
> >> for resolution and not registration. It is there primarily for
> >> frameworks that want to be IoC independent and is meant for low-level
> >> components.
> >>
> >> The problem is that you end up in the least common denominator to have
> >> such an interface. Every container has it's own unique features and
> >> they all tend to work differently. I'd recommend just choosing an IoC
> >> that works for you rather than creating some general wrapper.
> >>
> >> There is a project called MetaContainer on Codeplex though which
> >> provides the generic container abstraction you are looking for.
> >>
> >> Regards
> >> Glenn
> >>
> >> On 11/6/09, Chris Brandsma
> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
> >> > You want the Common Service Locator:
> >> >
> >> > http://commonservicelocator.codeplex.com/
> >> >
> >> > But realistically, most of your code (90% or more) should not know that
> >> > you
> >> > are using an IoC.
> >> >
> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
> >> >
> >> >>
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I've been testing several IOC frameworks now and there are alot that
> >> >> seem
> >> >> to suit most scenarios.
> >> >>
> >> >> I've been bitten in the past for choosing a particular implementation
> >> >> (such
> >> >> as logging) without implementing a wrapper for it, so that when it came
> >> >> to
> >> >> swap it out for another implementation it was a nightmare to do so.
> >> >>
> >> >> I was wondering is there a way to wrap an IOC implementation so I dont
> >> >> have
> >> >> the same nightmare in the future?
> >> >> Is there already an IOC wrapper out there that covers 90% of the common
> >> >> functionality?
> >> >>
> >> >> Tariq
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > --------------------------------
> >> > Christopher Brandsma
> >> > http://www.ChrisBrandsma.com
> >> > http://www.ElegantCode.com
> >> >
> >>
> >> --
> >> Sent from my mobile device
> >>
> >
> >
> >
>
> --
> Sent from my mobile device
>

[Glenn Block-2]

Sure. I was speaking about PC as an implementation of the concept. In
MEF land, PC provides a special purpose above and beyond just being a
factory. It returns an export rather than an instance. This is to
allow disposing the entire object graph (ie all non-shared imports).
As one of the imports 'might' be disposable. We have to worry about
stuff like this.

Generated factories in Autofac is a great solution and is container
agnostic. When Nick showed it to me, I really liked it. Also you can
just create a generic Factory<T> that takes a CSL in the ctor. This
way components can depend on it rather than the cotainer directly for
dynamic instantiated components.

The one thing MEF has that I don't think other containers have is the
ability to have the importer specify the lifetime policy and we have a
default export policy of Any. This allows part creator to request a
non-shared lifetime.version, as the idea of PC is you own anything it
creates.

However which ever way you do it is not the key, it is decoupling the
components from the container that is/

Regards
Glemn
Glenn

On 11/8/09, Patrik <patrik@...> wrote:

> Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast you
> did, can't remember which) but to me this ties you tighter to the
> IoC-specific implementation. The IoC in this case being MEF (don't shoot me
> for calling it an IoC). You can achieve the same thing by injecting some
> domain specific factory that just wraps the container. The way to do this in
> Autofac for example is through generated factories. The philosophy is pretty
> much the same though.
>
> As I said this is drawn from my quite shallow understanding of
> PartCreator<T> since I haven't taken a closer look at it since the web cast.
>
> Cheers mate,
> Patrik
>
> --- In altdotnet@..., Glenn Block <glenn.block@...> wrote:
>>
>> In MEF, we (Nick drove this) introduced a concept called
>> PartCreator<T>  which is essentially a generic factory that a
>> component takes a dependency. PartCreator allows components to spin up
>> new instances without having to be exposed to the container.
>>
>> You can create something simlar through a  Factory<T>. The factory
>> wraps a container and delegates calls to it.
>>
>> The factory is only used for cases where dynamic insantiation is needed.
>>
>> If you check Nick's blog you will see a post on this.
>>
>> On 11/7/09, Patrik <patrik@...> wrote:
>> > I totally agree with this, and I had to learn this the hard way,
>> > starting
>> > out using what's now considered an antipattern (static service locator)
>> > and
>> > moving on to using constructor injection and "injeted context". This
>> > keeps
>> > you IoC-container only at the infrastructure level and your code never
>> > has
>> > to know about it.
>> >
>> > Nicholas Blumhardt, the author of my favourite container Autofac wrote a
>> > couple of posts on this subject a year or so ago that starts with this
>> > post:
>> >
>> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
>> >
>> > Does anyone know of any good "example implementation" of this pattern
>> > that
>> > could guid "newbies"? I think that it's very easy to fall into the
>> > static
>> > service locator pit unless you have some guidance.
>> >
>> > /Patrik
>> >
>> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
>> >>
>> >> You shouldn't need a wrapper, since you should rather strive to make
>> >> all
>> >> your code DI Container-agnostic.
>> >>
>> >> Contrary to the use of a Service Locator (an anti-pattern if you ask
>> >> me),
>> >> DI can be implemented by using simple patterns such as Constructor
>> >> Injection. None of your classes that have dependencies need to
>> >> reference
>> >> any particular DI Container - they can just use their constructors to
>> >> publish what they need. Any DI Container will be able to auto-wire an
>> >> application and then get out of the way.
>> >>
>> >> It is only at the Composition Root that a DI Container should come into
>> >> play, and that is one very isolated place where you can easily replace
>> >> one
>> >> DI Container with another, so just pick one you like and use it like
>> >> that.
>> >>
>> >> Mark Seemann
>> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
>> >> Twitter: ploeh
>> >> ([phone]
>> >>
>> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
>> >>
>> >> From: altdotnet@... [mailto:altdotnet@...] On
>> >> Behalf Of Glenn Block
>> >> Sent: 7. november 2009 04:12
>> >> To: altdotnet@...
>> >> Subject: Re: [altdotnet] Wrapper for IOC functions
>> >>
>> >>
>> >>
>> >> CSL is not meant to be the uber abstraction / ioc. We designed it only
>> >> for resolution and not registration. It is there primarily for
>> >> frameworks that want to be IoC independent and is meant for low-level
>> >> components.
>> >>
>> >> The problem is that you end up in the least common denominator to have
>> >> such an interface. Every container has it's own unique features and
>> >> they all tend to work differently. I'd recommend just choosing an IoC
>> >> that works for you rather than creating some general wrapper.
>> >>
>> >> There is a project called MetaContainer on Codeplex though which
>> >> provides the generic container abstraction you are looking for.
>> >>
>> >> Regards
>> >> Glenn
>> >>
>> >> On 11/6/09, Chris Brandsma
>> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
>> >> > You want the Common Service Locator:
>> >> >
>> >> > http://commonservicelocator.codeplex.com/
>> >> >
>> >> > But realistically, most of your code (90% or more) should not know
>> >> > that
>> >> > you
>> >> > are using an IoC.
>> >> >
>> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
>> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I've been testing several IOC frameworks now and there are alot that
>> >> >> seem
>> >> >> to suit most scenarios.
>> >> >>
>> >> >> I've been bitten in the past for choosing a particular
>> >> >> implementation
>> >> >> (such
>> >> >> as logging) without implementing a wrapper for it, so that when it
>> >> >> came
>> >> >> to
>> >> >> swap it out for another implementation it was a nightmare to do so.
>> >> >>
>> >> >> I was wondering is there a way to wrap an IOC implementation so I
>> >> >> dont
>> >> >> have
>> >> >> the same nightmare in the future?
>> >> >> Is there already an IOC wrapper out there that covers 90% of the
>> >> >> common
>> >> >> functionality?
>> >> >>
>> >> >> Tariq
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > --------------------------------
>> >> > Christopher Brandsma
>> >> > http://www.ChrisBrandsma.com
>> >> > http://www.ElegantCode.com
>> >> >
>> >>
>> >> --
>> >> Sent from my mobile device
>> >>
>> >
>> >
>> >
>>
>> --
>> Sent from my mobile device
>>
>
>
>

--
Sent from my mobile device

[patrik.hagne-2]

I totally get the function of PC in MEF. Though, in the non-MEF-case, most of the time when I have dependencies on factories I need to pass arguments to the factories and I can't really figure out how this would be achieved with the Factory<T> general class. Maybe you could use "params object[] arguments" but I'd think you'd have difficulties implementing that for just any container.

I think you could just as well have dependencies on Func<T> which would allow you to take parameters (Func<int, string, IFoo>), when registered in the container it would just close over the container so that in fact you're container is injected behind the scenes. Personally I don't like to depend on unnamed Func<T> factories though, I'd much rather create a named delegate and depend on that, for example:

public delegate IFoo FooFactory(int aValue, string anotherValue);

Or in some cases where I might need more than one way to create a specific type (analogous to constructor overloading) I'd create an interface for the factory type (IFooFactory in this case). This would also apply if I need to control lifetime, then the factory could just implement IDisposable and delegate this to the container as well.

I think this would be applicable for any container though generated factories makes it even easier in Autofac for the delegate case. I don't have much experience with other containers though.

That's how I do it, but as I said earlier I've had a hard time finding much litterature or blog posts or any general knowledge on this subject and most of this I've had to come up with myself or pick up here and there along the way.

Could I make this easier with some generalization of Factory<T> that I'm missing? It would be delightful if that was the case, maybe I could take an extra weeks vacation next year? ;-)

Cheers,
Patrik

--- In altdotnet@..., Glenn Block <glenn.block@...> wrote:

>
> Sure. I was speaking about PC as an implementation of the concept. In
> MEF land, PC provides a special purpose above and beyond just being a
> factory. It returns an export rather than an instance. This is to
> allow disposing the entire object graph (ie all non-shared imports).
> As one of the imports 'might' be disposable. We have to worry about
> stuff like this.
>
> Generated factories in Autofac is a great solution and is container
> agnostic. When Nick showed it to me, I really liked it. Also you can
> just create a generic Factory<T> that takes a CSL in the ctor. This
> way components can depend on it rather than the cotainer directly for
> dynamic instantiated components.
>
> The one thing MEF has that I don't think other containers have is the
> ability to have the importer specify the lifetime policy and we have a
> default export policy of Any. This allows part creator to request a
> non-shared lifetime.version, as the idea of PC is you own anything it
> creates.
>
> However which ever way you do it is not the key, it is decoupling the
> components from the container that is/
>
> Regards
> Glemn
> Glenn
>
> On 11/8/09, Patrik <patrik@...> wrote:
> > Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast you
> > did, can't remember which) but to me this ties you tighter to the
> > IoC-specific implementation. The IoC in this case being MEF (don't shoot me
> > for calling it an IoC). You can achieve the same thing by injecting some
> > domain specific factory that just wraps the container. The way to do this in
> > Autofac for example is through generated factories. The philosophy is pretty
> > much the same though.
> >
> > As I said this is drawn from my quite shallow understanding of
> > PartCreator<T> since I haven't taken a closer look at it since the web cast.
> >
> > Cheers mate,
> > Patrik
> >
> > --- In altdotnet@..., Glenn Block <glenn.block@> wrote:
> >>
> >> In MEF, we (Nick drove this) introduced a concept called
> >> PartCreator<T>  which is essentially a generic factory that a
> >> component takes a dependency. PartCreator allows components to spin up
> >> new instances without having to be exposed to the container.
> >>
> >> You can create something simlar through a  Factory<T>. The factory
> >> wraps a container and delegates calls to it.
> >>
> >> The factory is only used for cases where dynamic insantiation is needed.
> >>
> >> If you check Nick's blog you will see a post on this.
> >>
> >> On 11/7/09, Patrik <patrik@> wrote:
> >> > I totally agree with this, and I had to learn this the hard way,
> >> > starting
> >> > out using what's now considered an antipattern (static service locator)
> >> > and
> >> > moving on to using constructor injection and "injeted context". This
> >> > keeps
> >> > you IoC-container only at the infrastructure level and your code never
> >> > has
> >> > to know about it.
> >> >
> >> > Nicholas Blumhardt, the author of my favourite container Autofac wrote a
> >> > couple of posts on this subject a year or so ago that starts with this
> >> > post:
> >> >
> >> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
> >> >
> >> > Does anyone know of any good "example implementation" of this pattern
> >> > that
> >> > could guid "newbies"? I think that it's very easy to fall into the
> >> > static
> >> > service locator pit unless you have some guidance.
> >> >
> >> > /Patrik
> >> >
> >> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
> >> >>
> >> >> You shouldn't need a wrapper, since you should rather strive to make
> >> >> all
> >> >> your code DI Container-agnostic.
> >> >>
> >> >> Contrary to the use of a Service Locator (an anti-pattern if you ask
> >> >> me),
> >> >> DI can be implemented by using simple patterns such as Constructor
> >> >> Injection. None of your classes that have dependencies need to
> >> >> reference
> >> >> any particular DI Container - they can just use their constructors to
> >> >> publish what they need. Any DI Container will be able to auto-wire an
> >> >> application and then get out of the way.
> >> >>
> >> >> It is only at the Composition Root that a DI Container should come into
> >> >> play, and that is one very isolated place where you can easily replace
> >> >> one
> >> >> DI Container with another, so just pick one you like and use it like
> >> >> that.
> >> >>
> >> >> Mark Seemann
> >> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
> >> >> Twitter: ploeh
> >> >> ([phone]
> >> >>
> >> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
> >> >>
> >> >> From: altdotnet@... [mailto:altdotnet@...] On
> >> >> Behalf Of Glenn Block
> >> >> Sent: 7. november 2009 04:12
> >> >> To: altdotnet@...
> >> >> Subject: Re: [altdotnet] Wrapper for IOC functions
> >> >>
> >> >>
> >> >>
> >> >> CSL is not meant to be the uber abstraction / ioc. We designed it only
> >> >> for resolution and not registration. It is there primarily for
> >> >> frameworks that want to be IoC independent and is meant for low-level
> >> >> components.
> >> >>
> >> >> The problem is that you end up in the least common denominator to have
> >> >> such an interface. Every container has it's own unique features and
> >> >> they all tend to work differently. I'd recommend just choosing an IoC
> >> >> that works for you rather than creating some general wrapper.
> >> >>
> >> >> There is a project called MetaContainer on Codeplex though which
> >> >> provides the generic container abstraction you are looking for.
> >> >>
> >> >> Regards
> >> >> Glenn
> >> >>
> >> >> On 11/6/09, Chris Brandsma
> >> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
> >> >> > You want the Common Service Locator:
> >> >> >
> >> >> > http://commonservicelocator.codeplex.com/
> >> >> >
> >> >> > But realistically, most of your code (90% or more) should not know
> >> >> > that
> >> >> > you
> >> >> > are using an IoC.
> >> >> >
> >> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> >> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I've been testing several IOC frameworks now and there are alot that
> >> >> >> seem
> >> >> >> to suit most scenarios.
> >> >> >>
> >> >> >> I've been bitten in the past for choosing a particular
> >> >> >> implementation
> >> >> >> (such
> >> >> >> as logging) without implementing a wrapper for it, so that when it
> >> >> >> came
> >> >> >> to
> >> >> >> swap it out for another implementation it was a nightmare to do so.
> >> >> >>
> >> >> >> I was wondering is there a way to wrap an IOC implementation so I
> >> >> >> dont
> >> >> >> have
> >> >> >> the same nightmare in the future?
> >> >> >> Is there already an IOC wrapper out there that covers 90% of the
> >> >> >> common
> >> >> >> functionality?
> >> >> >>
> >> >> >> Tariq
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > --------------------------------
> >> >> > Christopher Brandsma
> >> >> > http://www.ChrisBrandsma.com
> >> >> > http://www.ElegantCode.com
> >> >> >
> >> >>
> >> >> --
> >> >> Sent from my mobile device
> >> >>
> >> >
> >> >
> >> >
> >>
> >> --
> >> Sent from my mobile device
> >>
> >
> >
> >
>
> --
> Sent from my mobile device
>

[patrik.hagne-2]

--- In altdotnet@..., Glenn Block <glenn.block@...> wrote:

>
> Sure. I was speaking about PC as an implementation of the concept. In
> MEF land, PC provides a special purpose above and beyond just being a
> factory. It returns an export rather than an instance. This is to
> allow disposing the entire object graph (ie all non-shared imports).
> As one of the imports 'might' be disposable. We have to worry about
> stuff like this.
>
> Generated factories in Autofac is a great solution and is container
> agnostic. When Nick showed it to me, I really liked it. Also you can
> just create a generic Factory<T> that takes a CSL in the ctor. This
> way components can depend on it rather than the cotainer directly for
> dynamic instantiated components.
>
> The one thing MEF has that I don't think other containers have is the
> ability to have the importer specify the lifetime policy and we have a
> default export policy of Any. This allows part creator to request a
> non-shared lifetime.version, as the idea of PC is you own anything it
> creates.
>
> However which ever way you do it is not the key, it is decoupling the
> components from the container that is/
>
> Regards
> Glemn
> Glenn
>
> On 11/8/09, Patrik <patrik@...> wrote:
> > Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast you
> > did, can't remember which) but to me this ties you tighter to the
> > IoC-specific implementation. The IoC in this case being MEF (don't shoot me
> > for calling it an IoC). You can achieve the same thing by injecting some
> > domain specific factory that just wraps the container. The way to do this in
> > Autofac for example is through generated factories. The philosophy is pretty
> > much the same though.
> >
> > As I said this is drawn from my quite shallow understanding of
> > PartCreator<T> since I haven't taken a closer look at it since the web cast.
> >
> > Cheers mate,
> > Patrik
> >
> > --- In altdotnet@..., Glenn Block <glenn.block@> wrote:
> >>
> >> In MEF, we (Nick drove this) introduced a concept called
> >> PartCreator<T>  which is essentially a generic factory that a
> >> component takes a dependency. PartCreator allows components to spin up
> >> new instances without having to be exposed to the container.
> >>
> >> You can create something simlar through a  Factory<T>. The factory
> >> wraps a container and delegates calls to it.
> >>
> >> The factory is only used for cases where dynamic insantiation is needed.
> >>
> >> If you check Nick's blog you will see a post on this.
> >>
> >> On 11/7/09, Patrik <patrik@> wrote:
> >> > I totally agree with this, and I had to learn this the hard way,
> >> > starting
> >> > out using what's now considered an antipattern (static service locator)
> >> > and
> >> > moving on to using constructor injection and "injeted context". This
> >> > keeps
> >> > you IoC-container only at the infrastructure level and your code never
> >> > has
> >> > to know about it.
> >> >
> >> > Nicholas Blumhardt, the author of my favourite container Autofac wrote a
> >> > couple of posts on this subject a year or so ago that starts with this
> >> > post:
> >> >
> >> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
> >> >
> >> > Does anyone know of any good "example implementation" of this pattern
> >> > that
> >> > could guid "newbies"? I think that it's very easy to fall into the
> >> > static
> >> > service locator pit unless you have some guidance.
> >> >
> >> > /Patrik
> >> >
> >> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
> >> >>
> >> >> You shouldn't need a wrapper, since you should rather strive to make
> >> >> all
> >> >> your code DI Container-agnostic.
> >> >>
> >> >> Contrary to the use of a Service Locator (an anti-pattern if you ask
> >> >> me),
> >> >> DI can be implemented by using simple patterns such as Constructor
> >> >> Injection. None of your classes that have dependencies need to
> >> >> reference
> >> >> any particular DI Container - they can just use their constructors to
> >> >> publish what they need. Any DI Container will be able to auto-wire an
> >> >> application and then get out of the way.
> >> >>
> >> >> It is only at the Composition Root that a DI Container should come into
> >> >> play, and that is one very isolated place where you can easily replace
> >> >> one
> >> >> DI Container with another, so just pick one you like and use it like
> >> >> that.
> >> >>
> >> >> Mark Seemann
> >> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
> >> >> Twitter: ploeh
> >> >> ([phone]
> >> >>
> >> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
> >> >>
> >> >> From: altdotnet@... [mailto:altdotnet@...] On
> >> >> Behalf Of Glenn Block
> >> >> Sent: 7. november 2009 04:12
> >> >> To: altdotnet@...
> >> >> Subject: Re: [altdotnet] Wrapper for IOC functions
> >> >>
> >> >>
> >> >>
> >> >> CSL is not meant to be the uber abstraction / ioc. We designed it only
> >> >> for resolution and not registration. It is there primarily for
> >> >> frameworks that want to be IoC independent and is meant for low-level
> >> >> components.
> >> >>
> >> >> The problem is that you end up in the least common denominator to have
> >> >> such an interface. Every container has it's own unique features and
> >> >> they all tend to work differently. I'd recommend just choosing an IoC
> >> >> that works for you rather than creating some general wrapper.
> >> >>
> >> >> There is a project called MetaContainer on Codeplex though which
> >> >> provides the generic container abstraction you are looking for.
> >> >>
> >> >> Regards
> >> >> Glenn
> >> >>
> >> >> On 11/6/09, Chris Brandsma
> >> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
> >> >> > You want the Common Service Locator:
> >> >> >
> >> >> > http://commonservicelocator.codeplex.com/
> >> >> >
> >> >> > But realistically, most of your code (90% or more) should not know
> >> >> > that
> >> >> > you
> >> >> > are using an IoC.
> >> >> >
> >> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> >> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I've been testing several IOC frameworks now and there are alot that
> >> >> >> seem
> >> >> >> to suit most scenarios.
> >> >> >>
> >> >> >> I've been bitten in the past for choosing a particular
> >> >> >> implementation
> >> >> >> (such
> >> >> >> as logging) without implementing a wrapper for it, so that when it
> >> >> >> came
> >> >> >> to
> >> >> >> swap it out for another implementation it was a nightmare to do so.
> >> >> >>
> >> >> >> I was wondering is there a way to wrap an IOC implementation so I
> >> >> >> dont
> >> >> >> have
> >> >> >> the same nightmare in the future?
> >> >> >> Is there already an IOC wrapper out there that covers 90% of the
> >> >> >> common
> >> >> >> functionality?
> >> >> >>
> >> >> >> Tariq
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > --------------------------------
> >> >> > Christopher Brandsma
> >> >> > http://www.ChrisBrandsma.com
> >> >> > http://www.ElegantCode.com
> >> >> >
> >> >>
> >> >> --
> >> >> Sent from my mobile device
> >> >>
> >> >
> >> >
> >> >
> >>
> >> --
> >> Sent from my mobile device
> >>
> >
> >
> >
>
> --
> Sent from my mobile device
>

[patrik.hagne-2]

I totally get reasons for PC in MEF and I think it's a brilliant idea. Though, in the non-MEF-case, most of
the time when I have dependencies on factories I need to pass arguments to the
factories and I can't really figure out how this would be achieved with the
Factory<T> general class. Maybe you could use "params object[] arguments" but
I'd think you'd have difficulties implementing that for just any container.

I think you could just as well have dependencies on Func<T> which would allow
you to take parameters (Func<int, string, IFoo>), when registered in the
container it would just close over the container so that in fact you're
container is injected behind the scenes. Personally I don't like to depend on
unnamed Func<T> factories though, I'd much rather create a named delegate and
depend on that, for example:

public delegate IFoo FooFactory(int aValue, string anotherValue);

Or in some cases where I might need more than one way to create a specific type
(analogous to constructor overloading) I'd create an interface for the factory
type (IFooFactory in this case). This would also apply if I need to control
lifetime, then the factory could just implement IDisposable and delegate this to
the container as well.

I think this would be applicable for any container though generated factories
makes it even easier in Autofac for the delegate case. I don't have much
experience with other containers though.

That's how I do it, but as I said earlier I've had a hard time finding much
litterature or blog posts or any general knowledge on this subject and most of
this I've had to come up with myself or pick up here and there along the way.

Could I make this easier with some generalization of Factory<T> that I'm
missing? It would be delightful if that was the case, maybe I could take an
extra weeks vacation next year? ;-)

Cheers,
Patrik


--- In altdotnet@..., Glenn Block <glenn.block@...> wrote:

>
> Sure. I was speaking about PC as an implementation of the concept. In
> MEF land, PC provides a special purpose above and beyond just being a
> factory. It returns an export rather than an instance. This is to
> allow disposing the entire object graph (ie all non-shared imports).
> As one of the imports 'might' be disposable. We have to worry about
> stuff like this.
>
> Generated factories in Autofac is a great solution and is container
> agnostic. When Nick showed it to me, I really liked it. Also you can
> just create a generic Factory<T> that takes a CSL in the ctor. This
> way components can depend on it rather than the cotainer directly for
> dynamic instantiated components.
>
> The one thing MEF has that I don't think other containers have is the
> ability to have the importer specify the lifetime policy and we have a
> default export policy of Any. This allows part creator to request a
> non-shared lifetime.version, as the idea of PC is you own anything it
> creates.
>
> However which ever way you do it is not the key, it is decoupling the
> components from the container that is/
>
> Regards
> Glemn
> Glenn
>
> On 11/8/09, Patrik <patrik@...> wrote:
> > Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast you
> > did, can't remember which) but to me this ties you tighter to the
> > IoC-specific implementation. The IoC in this case being MEF (don't shoot me
> > for calling it an IoC). You can achieve the same thing by injecting some
> > domain specific factory that just wraps the container. The way to do this in
> > Autofac for example is through generated factories. The philosophy is pretty
> > much the same though.
> >
> > As I said this is drawn from my quite shallow understanding of
> > PartCreator<T> since I haven't taken a closer look at it since the web cast.
> >
> > Cheers mate,
> > Patrik
> >
> > --- In altdotnet@..., Glenn Block <glenn.block@> wrote:
> >>
> >> In MEF, we (Nick drove this) introduced a concept called
> >> PartCreator<T>  which is essentially a generic factory that a
> >> component takes a dependency. PartCreator allows components to spin up
> >> new instances without having to be exposed to the container.
> >>
> >> You can create something simlar through a  Factory<T>. The factory
> >> wraps a container and delegates calls to it.
> >>
> >> The factory is only used for cases where dynamic insantiation is needed.
> >>
> >> If you check Nick's blog you will see a post on this.
> >>
> >> On 11/7/09, Patrik <patrik@> wrote:
> >> > I totally agree with this, and I had to learn this the hard way,
> >> > starting
> >> > out using what's now considered an antipattern (static service locator)
> >> > and
> >> > moving on to using constructor injection and "injeted context". This
> >> > keeps
> >> > you IoC-container only at the infrastructure level and your code never
> >> > has
> >> > to know about it.
> >> >
> >> > Nicholas Blumhardt, the author of my favourite container Autofac wrote a
> >> > couple of posts on this subject a year or so ago that starts with this
> >> > post:
> >> >
> >> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
> >> >
> >> > Does anyone know of any good "example implementation" of this pattern
> >> > that
> >> > could guid "newbies"? I think that it's very easy to fall into the
> >> > static
> >> > service locator pit unless you have some guidance.
> >> >
> >> > /Patrik
> >> >
> >> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
> >> >>
> >> >> You shouldn't need a wrapper, since you should rather strive to make
> >> >> all
> >> >> your code DI Container-agnostic.
> >> >>
> >> >> Contrary to the use of a Service Locator (an anti-pattern if you ask
> >> >> me),
> >> >> DI can be implemented by using simple patterns such as Constructor
> >> >> Injection. None of your classes that have dependencies need to
> >> >> reference
> >> >> any particular DI Container - they can just use their constructors to
> >> >> publish what they need. Any DI Container will be able to auto-wire an
> >> >> application and then get out of the way.
> >> >>
> >> >> It is only at the Composition Root that a DI Container should come into
> >> >> play, and that is one very isolated place where you can easily replace
> >> >> one
> >> >> DI Container with another, so just pick one you like and use it like
> >> >> that.
> >> >>
> >> >> Mark Seemann
> >> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
> >> >> Twitter: ploeh
> >> >> ([phone]
> >> >>
> >> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
> >> >>
> >> >> From: altdotnet@... [mailto:altdotnet@...] On
> >> >> Behalf Of Glenn Block
> >> >> Sent: 7. november 2009 04:12
> >> >> To: altdotnet@...
> >> >> Subject: Re: [altdotnet] Wrapper for IOC functions
> >> >>
> >> >>
> >> >>
> >> >> CSL is not meant to be the uber abstraction / ioc. We designed it only
> >> >> for resolution and not registration. It is there primarily for
> >> >> frameworks that want to be IoC independent and is meant for low-level
> >> >> components.
> >> >>
> >> >> The problem is that you end up in the least common denominator to have
> >> >> such an interface. Every container has it's own unique features and
> >> >> they all tend to work differently. I'd recommend just choosing an IoC
> >> >> that works for you rather than creating some general wrapper.
> >> >>
> >> >> There is a project called MetaContainer on Codeplex though which
> >> >> provides the generic container abstraction you are looking for.
> >> >>
> >> >> Regards
> >> >> Glenn
> >> >>
> >> >> On 11/6/09, Chris Brandsma
> >> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
> >> >> > You want the Common Service Locator:
> >> >> >
> >> >> > http://commonservicelocator.codeplex.com/
> >> >> >
> >> >> > But realistically, most of your code (90% or more) should not know
> >> >> > that
> >> >> > you
> >> >> > are using an IoC.
> >> >> >
> >> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> >> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I've been testing several IOC frameworks now and there are alot that
> >> >> >> seem
> >> >> >> to suit most scenarios.
> >> >> >>
> >> >> >> I've been bitten in the past for choosing a particular
> >> >> >> implementation
> >> >> >> (such
> >> >> >> as logging) without implementing a wrapper for it, so that when it
> >> >> >> came
> >> >> >> to
> >> >> >> swap it out for another implementation it was a nightmare to do so.
> >> >> >>
> >> >> >> I was wondering is there a way to wrap an IOC implementation so I
> >> >> >> dont
> >> >> >> have
> >> >> >> the same nightmare in the future?
> >> >> >> Is there already an IOC wrapper out there that covers 90% of the
> >> >> >> common
> >> >> >> functionality?
> >> >> >>
> >> >> >> Tariq
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > --------------------------------
> >> >> > Christopher Brandsma
> >> >> > http://www.ChrisBrandsma.com
> >> >> > http://www.ElegantCode.com
> >> >> >
> >> >>
> >> >> --
> >> >> Sent from my mobile device
> >> >>
> >> >
> >> >
> >> >
> >>
> >> --
> >> Sent from my mobile device
> >>
> >
> >
> >
>
> --
> Sent from my mobile device
>

[Tariq Hassanen-2]

Ah yes, I know some do, but its just that i have seen some containers
require attributes, and that would mean being bound to an implementation.

I guess i can just use one that doesn't require that.


On Sat, Nov 7, 2009 at 9:44 PM, Mark Seemann <mark@...> wrote:

>
>
>  In other words; the Hollywood Principle applies: *Don't call your DI
> Container - it'll call you*.
>
>
>
> Mark Seemann
>
> http://blog.ploeh.dk
>
> Twitter: ploeh
>
> ([phone]
>
>
>
> Dependency Injection in .NET <http://www.manning.com/seemann/>
>
>
>
> *From:* altdotnet@... [mailto:altdotnet@...] *On
> Behalf Of *Mark Seemann
> *Sent:* 7. november 2009 09:58
> *To:* altdotnet@...
> *Subject:* RE: [altdotnet] Wrapper for IOC functions
>
>
>
>
>
> You shouldn't need a wrapper, since you should rather strive to make all
> your code DI Container-agnostic.
>
>
>
> Contrary to the use of a Service Locator (an anti-pattern if you ask me),
> DI can be implemented by using simple patterns such as Constructor
> Injection. None of your classes that have dependencies need to reference any
> particular DI Container - they can just use their constructors to publish
> what they need. Any DI Container will be able to auto-wire an application
> and then get out of the way.
>
>
>
> It is only at the Composition Root that a DI Container should come into
> play, and that is one very isolated place where you can easily replace one
> DI Container with another, so just pick one you like and use it like that.
>
>
>
> Mark Seemann
>
> http://blog.ploeh.dk
>
> Twitter: ploeh
>
> ([phone]
>
>
>
> Dependency Injection in .NET <http://www.manning.com/seemann/>
>
>
>
> *From:* altdotnet@... [mailto:altdotnet@...] *On
> Behalf Of *Glenn Block
> *Sent:* 7. november 2009 04:12
> *To:* altdotnet@...
> *Subject:* Re: [altdotnet] Wrapper for IOC functions
>
>
>
>
>
> CSL is not meant to be the uber abstraction / ioc. We designed it only
> for resolution and not registration. It is there primarily for
> frameworks that want to be IoC independent and is meant for low-level
> components.
>
> The problem is that you end up in the least common denominator to have
> such an interface. Every container has it's own unique features and
> they all tend to work differently. I'd recommend just choosing an IoC
> that works for you rather than creating some general wrapper.
>
> There is a project called MetaContainer on Codeplex though which
> provides the generic container abstraction you are looking for.
>
> Regards
> Glenn
>
> On 11/6/09, Chris Brandsma <chris.brandsma@...<chris.brandsma%40gmail.com>>
> wrote:
> > You want the Common Service Locator:
> >
> > http://commonservicelocator.codeplex.com/
> >
> > But realistically, most of your code (90% or more) should not know that
> you
> > are using an IoC.
> >
> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
> > <tariq.hassanen@... <tariq.hassanen%40gmail.com>>wrote:
> >
> >>
> >>
> >> Hi all,
> >>
> >> I've been testing several IOC frameworks now and there are alot that
> seem
> >> to suit most scenarios.
> >>
> >> I've been bitten in the past for choosing a particular implementation
> >> (such
> >> as logging) without implementing a wrapper for it, so that when it came
> to
> >> swap it out for another implementation it was a nightmare to do so.
> >>
> >> I was wondering is there a way to wrap an IOC implementation so I dont
> >> have
> >> the same nightmare in the future?
> >> Is there already an IOC wrapper out there that covers 90% of the common
> >> functionality?
> >>
> >> Tariq
> >>
> >>
> >
> >
> >
> > --
> > --------------------------------
> > Christopher Brandsma
> > http://www.ChrisBrandsma.com
> > http://www.ElegantCode.com
> >
>
> --
> Sent from my mobile device
>
>  
>

[Tariq Hassanen-2]

But also, theres going to be code at least somewhere that says
"container.Get<ISomeInterface>"

That cant happen automagically, or am I missing some major concept in the
design?

On Tue, Nov 10, 2009 at 10:13 AM, Tariq Hassanen
<tariq.hassanen@...>wrote:

> Ah yes, I know some do, but its just that i have seen some containers
> require attributes, and that would mean being bound to an implementation.
>
> I guess i can just use one that doesn't require that.
>
>
> On Sat, Nov 7, 2009 at 9:44 PM, Mark Seemann <mark@...> wrote:
>
>>
>>
>>  In other words; the Hollywood Principle applies: *Don't call your DI
>> Container - it'll call you*.
>>
>>
>>
>> Mark Seemann
>>
>> http://blog.ploeh.dk
>>
>> Twitter: ploeh
>>
>> ([phone]
>>
>>
>>
>> Dependency Injection in .NET <http://www.manning.com/seemann/>
>>
>>
>>
>> *From:* altdotnet@... [mailto:altdotnet@...] *On
>> Behalf Of *Mark Seemann
>> *Sent:* 7. november 2009 09:58
>> *To:* altdotnet@...
>> *Subject:* RE: [altdotnet] Wrapper for IOC functions
>>
>>
>>
>>
>>
>> You shouldn't need a wrapper, since you should rather strive to make all
>> your code DI Container-agnostic.
>>
>>
>>
>> Contrary to the use of a Service Locator (an anti-pattern if you ask me),
>> DI can be implemented by using simple patterns such as Constructor
>> Injection. None of your classes that have dependencies need to reference any
>> particular DI Container - they can just use their constructors to publish
>> what they need. Any DI Container will be able to auto-wire an application
>> and then get out of the way.
>>
>>
>>
>> It is only at the Composition Root that a DI Container should come into
>> play, and that is one very isolated place where you can easily replace one
>> DI Container with another, so just pick one you like and use it like that.
>>
>>
>>
>> Mark Seemann
>>
>> http://blog.ploeh.dk
>>
>> Twitter: ploeh
>>
>> ([phone]
>>
>>
>>
>> Dependency Injection in .NET <http://www.manning.com/seemann/>
>>
>>
>>
>> *From:* altdotnet@... [mailto:altdotnet@...] *On
>> Behalf Of *Glenn Block
>> *Sent:* 7. november 2009 04:12
>> *To:* altdotnet@...
>> *Subject:* Re: [altdotnet] Wrapper for IOC functions
>>
>>
>>
>>
>>
>> CSL is not meant to be the uber abstraction / ioc. We designed it only
>> for resolution and not registration. It is there primarily for
>> frameworks that want to be IoC independent and is meant for low-level
>> components.
>>
>> The problem is that you end up in the least common denominator to have
>> such an interface. Every container has it's own unique features and
>> they all tend to work differently. I'd recommend just choosing an IoC
>> that works for you rather than creating some general wrapper.
>>
>> There is a project called MetaContainer on Codeplex though which
>> provides the generic container abstraction you are looking for.
>>
>> Regards
>> Glenn
>>
>> On 11/6/09, Chris Brandsma <chris.brandsma@...<chris.brandsma%40gmail.com>>
>> wrote:
>> > You want the Common Service Locator:
>> >
>> > http://commonservicelocator.codeplex.com/
>> >
>> > But realistically, most of your code (90% or more) should not know that
>> you
>> > are using an IoC.
>> >
>> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
>> > <tariq.hassanen@... <tariq.hassanen%40gmail.com>>wrote:
>> >
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I've been testing several IOC frameworks now and there are alot that
>> seem
>> >> to suit most scenarios.
>> >>
>> >> I've been bitten in the past for choosing a particular implementation
>> >> (such
>> >> as logging) without implementing a wrapper for it, so that when it came
>> to
>> >> swap it out for another implementation it was a nightmare to do so.
>> >>
>> >> I was wondering is there a way to wrap an IOC implementation so I dont
>> >> have
>> >> the same nightmare in the future?
>> >> Is there already an IOC wrapper out there that covers 90% of the common
>> >> functionality?
>> >>
>> >> Tariq
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > --------------------------------
>> > Christopher Brandsma
>> > http://www.ChrisBrandsma.com
>> > http://www.ElegantCode.com
>> >
>>
>> --
>> Sent from my mobile device
>>
>>  
>>
>
>

[mark.nijhof]

You will need one place in your code where you make a  call to the
container, this would normally be the starting point of the application
f.ex. application start, webservice start or the mvc controler factory, what
ever it is that gets executed first. then form there on all dependencies
should be automatically injected in the classes needing it. So only these
stating points need to know about your IoC. And of course your configuration
code. Now there will be some exemptions to this rule, because you want
something special from your container, but I would say less than 95% of your
code knows about the IoC.

-Mark

On Tue, Nov 10, 2009 at 12:34 AM, Tariq Hassanen
<tariq.hassanen@...>wrote:

>
>
> But also, theres going to be code at least somewhere that says
> "container.Get<ISomeInterface>"
>
> That cant happen automagically, or am I missing some major concept in the
> design?
>
>
> On Tue, Nov 10, 2009 at 10:13 AM, Tariq Hassanen <tariq.hassanen@...
> > wrote:
>
>> Ah yes, I know some do, but its just that i have seen some containers
>> require attributes, and that would mean being bound to an implementation.
>>
>> I guess i can just use one that doesn't require that.
>>
>>
>> On Sat, Nov 7, 2009 at 9:44 PM, Mark Seemann <mark@...> wrote:
>>
>>>
>>>
>>>  In other words; the Hollywood Principle applies: *Don't call your DI
>>> Container - it'll call you*.
>>>
>>>
>>>
>>> Mark Seemann
>>>
>>> http://blog.ploeh.dk
>>>
>>> Twitter: ploeh
>>>
>>> ([phone]
>>>
>>>
>>>
>>> Dependency Injection in .NET <http://www.manning.com/seemann/>
>>>
>>>
>>>
>>> *From:* altdotnet@... [mailto:altdotnet@...] *On
>>> Behalf Of *Mark Seemann
>>> *Sent:* 7. november 2009 09:58
>>> *To:* altdotnet@...
>>> *Subject:* RE: [altdotnet] Wrapper for IOC functions
>>>
>>>
>>>
>>>
>>>
>>> You shouldn't need a wrapper, since you should rather strive to make all
>>> your code DI Container-agnostic.
>>>
>>>
>>>
>>> Contrary to the use of a Service Locator (an anti-pattern if you ask me),
>>> DI can be implemented by using simple patterns such as Constructor
>>> Injection. None of your classes that have dependencies need to reference any
>>> particular DI Container - they can just use their constructors to publish
>>> what they need. Any DI Container will be able to auto-wire an application
>>> and then get out of the way.
>>>
>>>
>>>
>>> It is only at the Composition Root that a DI Container should come into
>>> play, and that is one very isolated place where you can easily replace one
>>> DI Container with another, so just pick one you like and use it like that.
>>>
>>>
>>>
>>> Mark Seemann
>>>
>>> http://blog.ploeh.dk
>>>
>>> Twitter: ploeh
>>>
>>> ([phone]
>>>
>>>
>>>
>>> Dependency Injection in .NET <http://www.manning.com/seemann/>
>>>
>>>
>>>
>>> *From:* altdotnet@... [mailto:altdotnet@...] *On
>>> Behalf Of *Glenn Block
>>> *Sent:* 7. november 2009 04:12
>>> *To:* altdotnet@...
>>> *Subject:* Re: [altdotnet] Wrapper for IOC functions
>>>
>>>
>>>
>>>
>>>
>>> CSL is not meant to be the uber abstraction / ioc. We designed it only
>>> for resolution and not registration. It is there primarily for
>>> frameworks that want to be IoC independent and is meant for low-level
>>> components.
>>>
>>> The problem is that you end up in the least common denominator to have
>>> such an interface. Every container has it's own unique features and
>>> they all tend to work differently. I'd recommend just choosing an IoC
>>> that works for you rather than creating some general wrapper.
>>>
>>> There is a project called MetaContainer on Codeplex though which
>>> provides the generic container abstraction you are looking for.
>>>
>>> Regards
>>> Glenn
>>>
>>> On 11/6/09, Chris Brandsma <chris.brandsma@...<chris.brandsma%40gmail.com>>
>>> wrote:
>>> > You want the Common Service Locator:
>>> >
>>> > http://commonservicelocator.codeplex.com/
>>> >
>>> > But realistically, most of your code (90% or more) should not know that
>>> you
>>> > are using an IoC.
>>> >
>>> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
>>> > <tariq.hassanen@... <tariq.hassanen%40gmail.com>>wrote:
>>> >
>>> >>
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I've been testing several IOC frameworks now and there are alot that
>>> seem
>>> >> to suit most scenarios.
>>> >>
>>> >> I've been bitten in the past for choosing a particular implementation
>>> >> (such
>>> >> as logging) without implementing a wrapper for it, so that when it
>>> came to
>>> >> swap it out for another implementation it was a nightmare to do so.
>>> >>
>>> >> I was wondering is there a way to wrap an IOC implementation so I dont
>>> >> have
>>> >> the same nightmare in the future?
>>> >> Is there already an IOC wrapper out there that covers 90% of the
>>> common
>>> >> functionality?
>>> >>
>>> >> Tariq
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > --------------------------------
>>> > Christopher Brandsma
>>> > http://www.ChrisBrandsma.com
>>> > http://www.ElegantCode.com
>>> >
>>>
>>> --
>>> Sent from my mobile device
>>>
>>>
>>
>  
>

[Glenn Block-2]

You are right, Factory<T> doesn't solve the parameters problem. MEF
Let's you export methods, so that is one way to do custom factories
that have contextual params but it is MEF specific.

One idea is to extend the generic params, so Factory<T,TParams>. Then
in the implementation, have it pass in the params to the container.
The factory would then require passing a TParams arg to the create
method.

Glenn

On 11/9/09, Patrik <patrik@...> wrote:

> I totally get the function of PC in MEF. Though, in the non-MEF-case, most
> of the time when I have dependencies on factories I need to pass arguments
> to the factories and I can't really figure out how this would be achieved
> with the Factory<T> general class. Maybe you could use "params object[]
> arguments" but I'd think you'd have difficulties implementing that for just
> any container.
>
> I think you could just as well have dependencies on Func<T> which would
> allow you to take parameters (Func<int, string, IFoo>), when registered in
> the container it would just close over the container so that in fact you're
> container is injected behind the scenes. Personally I don't like to depend
> on unnamed Func<T> factories though, I'd much rather create a named delegate
> and depend on that, for example:
>
> public delegate IFoo FooFactory(int aValue, string anotherValue);
>
> Or in some cases where I might need more than one way to create a specific
> type (analogous to constructor overloading) I'd create an interface for the
> factory type (IFooFactory in this case). This would also apply if I need to
> control lifetime, then the factory could just implement IDisposable and
> delegate this to the container as well.
>
> I think this would be applicable for any container though generated
> factories makes it even easier in Autofac for the delegate case. I don't
> have much experience with other containers though.
>
> That's how I do it, but as I said earlier I've had a hard time finding much
> litterature or blog posts or any general knowledge on this subject and most
> of this I've had to come up with myself or pick up here and there along the
> way.
>
> Could I make this easier with some generalization of Factory<T> that I'm
> missing? It would be delightful if that was the case, maybe I could take an
> extra weeks vacation next year? ;-)
>
> Cheers,
> Patrik
>
> --- In altdotnet@..., Glenn Block <glenn.block@...> wrote:
>>
>> Sure. I was speaking about PC as an implementation of the concept. In
>> MEF land, PC provides a special purpose above and beyond just being a
>> factory. It returns an export rather than an instance. This is to
>> allow disposing the entire object graph (ie all non-shared imports).
>> As one of the imports 'might' be disposable. We have to worry about
>> stuff like this.
>>
>> Generated factories in Autofac is a great solution and is container
>> agnostic. When Nick showed it to me, I really liked it. Also you can
>> just create a generic Factory<T> that takes a CSL in the ctor. This
>> way components can depend on it rather than the cotainer directly for
>> dynamic instantiated components.
>>
>> The one thing MEF has that I don't think other containers have is the
>> ability to have the importer specify the lifetime policy and we have a
>> default export policy of Any. This allows part creator to request a
>> non-shared lifetime.version, as the idea of PC is you own anything it
>> creates.
>>
>> However which ever way you do it is not the key, it is decoupling the
>> components from the container that is/
>>
>> Regards
>> Glemn
>> Glenn
>>
>> On 11/8/09, Patrik <patrik@...> wrote:
>> > Yes Glenn, I know (slightly) about PartCreator<T> (from some web cast
>> > you
>> > did, can't remember which) but to me this ties you tighter to the
>> > IoC-specific implementation. The IoC in this case being MEF (don't shoot
>> > me
>> > for calling it an IoC). You can achieve the same thing by injecting some
>> > domain specific factory that just wraps the container. The way to do
>> > this in
>> > Autofac for example is through generated factories. The philosophy is
>> > pretty
>> > much the same though.
>> >
>> > As I said this is drawn from my quite shallow understanding of
>> > PartCreator<T> since I haven't taken a closer look at it since the web
>> > cast.
>> >
>> > Cheers mate,
>> > Patrik
>> >
>> > --- In altdotnet@..., Glenn Block <glenn.block@> wrote:
>> >>
>> >> In MEF, we (Nick drove this) introduced a concept called
>> >> PartCreator<T>  which is essentially a generic factory that a
>> >> component takes a dependency. PartCreator allows components to spin up
>> >> new instances without having to be exposed to the container.
>> >>
>> >> You can create something simlar through a  Factory<T>. The factory
>> >> wraps a container and delegates calls to it.
>> >>
>> >> The factory is only used for cases where dynamic insantiation is
>> >> needed.
>> >>
>> >> If you check Nick's blog you will see a post on this.
>> >>
>> >> On 11/7/09, Patrik <patrik@> wrote:
>> >> > I totally agree with this, and I had to learn this the hard way,
>> >> > starting
>> >> > out using what's now considered an antipattern (static service
>> >> > locator)
>> >> > and
>> >> > moving on to using constructor injection and "injeted context". This
>> >> > keeps
>> >> > you IoC-container only at the infrastructure level and your code
>> >> > never
>> >> > has
>> >> > to know about it.
>> >> >
>> >> > Nicholas Blumhardt, the author of my favourite container Autofac
>> >> > wrote a
>> >> > couple of posts on this subject a year or so ago that starts with
>> >> > this
>> >> > post:
>> >> >
>> >> > http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx
>> >> >
>> >> > Does anyone know of any good "example implementation" of this pattern
>> >> > that
>> >> > could guid "newbies"? I think that it's very easy to fall into the
>> >> > static
>> >> > service locator pit unless you have some guidance.
>> >> >
>> >> > /Patrik
>> >> >
>> >> > --- In altdotnet@..., Mark Seemann <mark@> wrote:
>> >> >>
>> >> >> You shouldn't need a wrapper, since you should rather strive to make
>> >> >> all
>> >> >> your code DI Container-agnostic.
>> >> >>
>> >> >> Contrary to the use of a Service Locator (an anti-pattern if you ask
>> >> >> me),
>> >> >> DI can be implemented by using simple patterns such as Constructor
>> >> >> Injection. None of your classes that have dependencies need to
>> >> >> reference
>> >> >> any particular DI Container - they can just use their constructors
>> >> >> to
>> >> >> publish what they need. Any DI Container will be able to auto-wire
>> >> >> an
>> >> >> application and then get out of the way.
>> >> >>
>> >> >> It is only at the Composition Root that a DI Container should come
>> >> >> into
>> >> >> play, and that is one very isolated place where you can easily
>> >> >> replace
>> >> >> one
>> >> >> DI Container with another, so just pick one you like and use it like
>> >> >> that.
>> >> >>
>> >> >> Mark Seemann
>> >> >> http://blog.ploeh.dk<http://blog.ploeh.dk/>
>> >> >> Twitter: ploeh
>> >> >> ([phone]
>> >> >>
>> >> >> Dependency Injection in .NET<http://www.manning.com/seemann/>
>> >> >>
>> >> >> From: altdotnet@... [mailto:altdotnet@...]
>> >> >> On
>> >> >> Behalf Of Glenn Block
>> >> >> Sent: 7. november 2009 04:12
>> >> >> To: altdotnet@...
>> >> >> Subject: Re: [altdotnet] Wrapper for IOC functions
>> >> >>
>> >> >>
>> >> >>
>> >> >> CSL is not meant to be the uber abstraction / ioc. We designed it
>> >> >> only
>> >> >> for resolution and not registration. It is there primarily for
>> >> >> frameworks that want to be IoC independent and is meant for
>> >> >> low-level
>> >> >> components.
>> >> >>
>> >> >> The problem is that you end up in the least common denominator to
>> >> >> have
>> >> >> such an interface. Every container has it's own unique features and
>> >> >> they all tend to work differently. I'd recommend just choosing an
>> >> >> IoC
>> >> >> that works for you rather than creating some general wrapper.
>> >> >>
>> >> >> There is a project called MetaContainer on Codeplex though which
>> >> >> provides the generic container abstraction you are looking for.
>> >> >>
>> >> >> Regards
>> >> >> Glenn
>> >> >>
>> >> >> On 11/6/09, Chris Brandsma
>> >> >> <chris.brandsma@<mailto:chris.brandsma%40gmail.com>> wrote:
>> >> >> > You want the Common Service Locator:
>> >> >> >
>> >> >> > http://commonservicelocator.codeplex.com/
>> >> >> >
>> >> >> > But realistically, most of your code (90% or more) should not know
>> >> >> > that
>> >> >> > you
>> >> >> > are using an IoC.
>> >> >> >
>> >> >> > On Fri, Nov 6, 2009 at 3:31 PM, Tariq Hassanen
>> >> >> > <tariq.hassanen@<mailto:tariq.hassanen%40gmail.com>>wrote:
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I've been testing several IOC frameworks now and there are alot
>> >> >> >> that
>> >> >> >> seem
>> >> >> >> to suit most scenarios.
>> >> >> >>
>> >> >> >> I've been bitten in the past for choosing a particular
>> >> >> >> implementation
>> >> >> >> (such
>> >> >> >> as logging) without implementing a wrapper for it, so that when
>> >> >> >> it
>> >> >> >> came
>> >> >> >> to
>> >> >> >> swap it out for another implementation it was a nightmare to do
>> >> >> >> so.
>> >> >> >>
>> >> >> >> I was wondering is there a way to wrap an IOC implementation so I
>> >> >> >> dont
>> >> >> >> have
>> >> >> >> the same nightmare in the future?
>> >> >> >> Is there already an IOC wrapper out there that covers 90% of the
>> >> >> >> common
>> >> >> >> functionality?
>> >> >> >>
>> >> >> >> Tariq
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > --------------------------------
>> >> >> > Christopher Brandsma
>> >> >> > http://www.ChrisBrandsma.com
>> >> >> > http://www.ElegantCode.com
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> Sent from my mobile device
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> Sent from my mobile device
>> >>
>> >
>> >
>> >
>>
>> --
>> Sent from my mobile device
>>
>
>
>

--
Sent from my mobile device

[carmour24]

I was under the impression that, for example with IContext in Autofac, this is one of the reasons that an IoC container would inject a context into an object.  That context could provide such facilities as resolution without directly providing access to the container itself.

--- In altdotnet@..., Glenn Block <glenn.block@...> wrote:

>
> You are right, Factory<T> doesn't solve the parameters problem. MEF
> Let's you export methods, so that is one way to do custom factories
> that have contextual params but it is MEF specific.
>
> One idea is to extend the generic params, so Factory<T,TParams>. Then
> in the implementation, have it pass in the params to the container.
> The factory would then require passing a TParams arg to the create
> method.
>
> Glenn