Suggestion on choosing IOC Container

[Zhou Yong]

Hi guys,

Currently I am using Ninject, but I have issue as follows:

The current stable build of Ninject is based on .NET Framework 2.0, and has duplicate lots of classes from System.Core.dll of .NET Framework 3.5, one of the most annoying class among them System.Runtime.CompilerServices.ExtensionAttribute. which is conflicting with the same class with the same full name inside System.Core, Version=3.5.0.0.
Which is annoying and I regard it as a show stopper, since we cannot reference the System.Core.dll if we already referenced Ninject.Core.dll in a single project.

Ninject 2.0 which target .NET Framework 3.5 is in beta stage, and it seems it's not continued by the author:

http://github.com/enkari/ninject

The workaround is to put the Ninject related stuff into a separate clean assembly, but that's a kind of hack since we have too many assemblies right now, and I am not so convinced about creating another assembly just for workaround this particular issue.

There are many IOC containers over there:
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

I've experimented with Windsor Castle before, and I think it's good, but just a little bit over bloated, since it's build around XML based configuration system which I don't use, I prefer code based configuration approach, I'd rather like to choose something much more lightweight for pure client application.

Guys, which IOC container you guys use for MVVM based WPF client application development? and what's your story in using them?

MarcoZ

[Michael Sync]

I'm using Unity. I'm totally happy with it.. 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Paul Stovell]

I tend to use Autofac for most new work - you can see how I used it with MVP and Composite WPF here:

http://www.paulstovell.com/wpf-model-view-presenter

Prior to Autofac I used Castle and Ninject. Coming from Ninject you'll find Autofac has all the features you expect and Nick is doing some very interesting work around adapters and lifetime management. 

Paul

--
Paul Stovell

[Corrado Cavalli]

Same here...

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Michael Sync
Sent: mercoledì 24 febbraio 2010 08:48
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Suggestion on choosing IOC Container

 

I'm using Unity. I'm totally happy with it.. 

 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Peter O'Hanlon]

I've used Castle, but I was never as happy with it as I was with his other stuff; like Active Record. I much prefer Unity as a straightforward IOC container; although I have to give a big shout out to MEF here - I now mainly use MEF, it's not just an IoC container and it's pretty durn cool - although I do wish it had native support for open generics (kudos to Glenn for his implementation of an open generic container, but it has limitations that are hard to get round).

--
Peter O'Hanlon

[Zhou Yong]

Thanks dude for all your suggestions.

As for MEF, I don't like its [Export], [Import] attribute decorations, I use constructor injection in only one or two places(for infrastructure purpose only), and at other circumstances, I use service locator approach. I don't think MEF could be treated as a general purpose IOC container, since it's designed for open system rather than closed system.

I am glad to hear from Glenn, and his comments and suggestions on MEF as IOC container, or his choice of container here?

MarcoZ

[Peter O'Hanlon]

The attribute approach in MEF doesn't bother me. After all, it's only another way of signalling intent - on one side, you have the interface that you are going to import (btw, you can always use InheritedExport on these interfaces to signal that you always want concrete implementations of that interface to be exported); on the other side you have the area that you are going to import into. Personally speaking, I think that MEF is a huge step forward, and that it solves a lot of problems that is a real PITA when writing your own plugin architecture.

--
Peter O'Hanlon

[Daniel Vaughan]

+1 Unity

On Feb 24, 8:47 am, Michael Sync <mchls...@gmail.com> wrote:
> I'm using Unity. I'm totally happy with it..
>
> Thanks and Best Regards,
> Michael Sync
>
> Don't go the way life takes you.
> Take life the way you go
>
> http://michaelsync.net
>

> On Wed, Feb 24, 2010 at 3:09 PM, Zhou Yong <football...@gmail.com> wrote:
> > Hi guys,
>
> > Currently I am using Ninject, but I have issue as follows:
>
> > The current stable build of Ninject is based on .NET Framework 2.0, and has
> > duplicate lots of classes from System.Core.dll of .NET Framework 3.5, one of
> > the most annoying class among them
> > System.Runtime.CompilerServices.ExtensionAttribute. which is conflicting
> > with the same class with the same full name inside System.Core,
> > Version=3.5.0.0.
> > Which is annoying and I regard it as a show stopper, since we cannot
> > reference the System.Core.dll if we already referenced Ninject.Core.dll in a
> > single project.
>
> > Ninject 2.0 which target .NET Framework 3.5 is in beta stage, and it seems
> > it's not continued by the author:
>
> >http://github.com/enkari/ninject
>
> > The workaround is to put the Ninject related stuff into a separate clean
> > assembly, but that's a kind of hack since we have too many assemblies right
> > now, and I am not so convinced about creating another assembly just for
> > workaround this particular issue.
>
> > There are many IOC containers over there:
>

> >http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersI...

[Daniel Vaughan]

The first thing I noticed with the autofac approach was the similarity
to Unity's StaticFactoryExtension, where you register a lambda/type
association.

On Feb 24, 9:22 am, Paul Stovell <p...@paulstovell.com> wrote:
> I tend to use Autofac <http://code.google.com/p/autofac/> for most new work

> - you can see how I used it with MVP and Composite WPF here:
>
> http://www.paulstovell.com/wpf-model-view-presenter
>
> Prior to Autofac I used Castle and Ninject. Coming from Ninject you'll find
> Autofac has all the features you expect and Nick is doing some very
> interesting work around adapters and lifetime management.
>
> Paul

> <http://www.paulstovell.com/wpf-model-view-presenter>

>
>
>
> On Wed, Feb 24, 2010 at 6:09 PM, Zhou Yong <football...@gmail.com> wrote:
> > Hi guys,
>
> > Currently I am using Ninject, but I have issue as follows:
>
> > The current stable build of Ninject is based on .NET Framework 2.0, and has
> > duplicate lots of classes from System.Core.dll of .NET Framework 3.5, one of
> > the most annoying class among them
> > System.Runtime.CompilerServices.ExtensionAttribute. which is conflicting
> > with the same class with the same full name inside System.Core,
> > Version=3.5.0.0.
> > Which is annoying and I regard it as a show stopper, since we cannot
> > reference the System.Core.dll if we already referenced Ninject.Core.dll in a
> > single project.
>
> > Ninject 2.0 which target .NET Framework 3.5 is in beta stage, and it seems
> > it's not continued by the author:
>
> >http://github.com/enkari/ninject
>
> > The workaround is to put the Ninject related stuff into a separate clean
> > assembly, but that's a kind of hack since we have too many assemblies right
> > now, and I am not so convinced about creating another assembly just for
> > workaround this particular issue.
>
> > There are many IOC containers over there:
>

> >http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersI...

[Michael Sync]

>>I am glad to hear from Glenn, and his comments and suggestions on MEF as IOC container, or his choice of container here?

I remember that he wrote about that in his blog once. You can search that post in his blog. 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Michael Sync]

Found it. Here is the link http://codebetter.com/blogs/glenn.block/archive/2009/08/16/should-i-use-mef-for-my-general-ioc-needs.aspx 

Thanks and Best Regards,
Michael Sync

Don't go the way life takes you.
Take life the way you go

http://michaelsync.net

[Glenn Block]

Autofac is ny favorite these days, though I am biased from working
with Nick. It is very light and extremely powerful and easy to use.
All great traits!

On 2/24/10, Paul Stovell <pa...@paulstovell.com> wrote:
> I tend to use Autofac <http://code.google.com/p/autofac/> for most new work

> - you can see how I used it with MVP and Composite WPF here:
>
> http://www.paulstovell.com/wpf-model-view-presenter
>
> Prior to Autofac I used Castle and Ninject. Coming from Ninject you'll find
> Autofac has all the features you expect and Nick is doing some very
> interesting work around adapters and lifetime management.
>
> Paul

> <http://www.paulstovell.com/wpf-model-view-presenter>

--
Sent from my mobile device

[Glenn Block]

MEF's greatest strength is removing the need for any host registration
as well as it's lazy and metadara facilities which allow systems to
adapt based on the available components.

After using MEF for a while you quickly see the benefits and the
attribs don't get in the way. We also allow you to put exports on the
interface itself through usage of InheritedExport which removes the
need for attributing exporters. Finally you can create your own domain
specific attributes which express exports / imports on your own terms.

As far as using it for your general IoC needs, we've never said you
cannot do it, we've said consider your needs and how they match up. If
open generics, aop, centralized config / convention over attributes
are all critical then MEF may not be the best choice.

I use it though for many of my basic IoC needs and it works.

It is all about proper expectations.

Glenn

--

[Glenn Block]

Just as a side note, MEF inherently does support non-attributed parts
through our ReflectionModelServices API. Andreas Haakanson
(@TheCodeJunlkie) will be shortly shipping a fluent / convention based
API on MEF contrib that uses this.

By a show of hands, how many folks would use MEF if not for attributes?

Glenn

On 2/24/10, Zhou Yong <footb...@gmail.com> wrote:

--