CommonServiceLocator instead of Ninject

[Simone Busoli]

As you know, I don't like coupling to a specific framework, so why not go with the newly released CommonServiceLocator  instead of Ninject?

Details here: http://codebetter.com/blogs/glenn.block/archive/2008/10/02/iservicelocator-a-step-toward-ioc-container-service-locator-detente.aspx

[Johannes Athmer]

Hej

On 2 Okt., 13:09, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> As you know, I don't like coupling to a specific framework

Which, I believe, is a good thing. Especially when designing another
framework.

> so why not go with the newly released CommonServiceLocator

> <http://www.codeplex.com/CommonServiceLocator> instead of Ninject?
> Details here:
> <http://codebetter.com/blogs/glenn.block/archive/2008/10/02/iservicelocator-a-step-toward-ioc-container-service-locator-detente.aspx>

Given the fact that much more experienced coders than me worked on
this for quite some time, my concern with this library probably is not
as weird as I think right now. :D What I find weird is to introduce a
static class which provides access to IServiceLocator. A generic
access to this is required for sure, but using a static class
introduces to danger of having people use the ServiceLocator.Current
inside their classes instead of having some ISomething object injected
somewhere. This would probably still be some kind of depedency
injection (as the class has no clue about the implementation of
IServiceLocator), but it would not really be IoC any more, because a
calling class could easily demand creation of an object that way,
right?
Anyway, this probably does not belong here. :)

As for S#arp Architecture, I think that the current integration of
Ninject is quite painless because of the MVC Contrib module. In order
to switching to a more generic interface as the Common Service
Locator, one should probably wait until it is supported by MVC
Contrib.

-Johannes

[Simone Busoli]

That's why I proposed the switch on the mvccontrib mailing list, but there seems to be issues with Windsor, since it needs to call Release on the components which implement the IDisposable interface (like controllers do), and a corresponding method is not exposed by the IServiceLocator interface.

[Billy]

Thanks for the suggestion Simone. For now, I'm pleased with Ninject's
ease of use, simple configuration requirements, and decoupled behavior
when compared to alternatives. But please let me know if you feel
that the Common Service Locator evolves to have additional advantages
than Ninject.

Thanks again for the suggestion,
Billy

[Simone Busoli]

Well, CommonServiceLocator in the end is just a simple interface which several IoC containers are already distributing adapters for to make it easy for frameworks to adopt inversion of control without tying to a specific container. Since #arch is something I would like to use without tying myself to Ninject, CSL would definitely be a good way to go.

Right now CSL is not yet supported by Ninject, but I think it will soon.

[Billy]

Now that I took the time to have a better understanding of Common
Service Locator, I believe it best, as you suggested, to include it
once Ninject support is completed by Nate.

Billy

On Oct 7, 5:25 pm, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> Well, CommonServiceLocator in the end is just a simple interface which
> several IoC containers are already distributing adapters for to make it easy
> for frameworks to adopt inversion of control without tying to a specific
> container. Since #arch is something I would like to use without tying myself

> to Ninject, CSL would definitely be a good way to go.Right now CSL is not

> yet supported by Ninject, but I think it will soon.
>

[Simone Busoli]

Glad to hear Billy!