NuGet Package and CommonServiceLocator.NinjectAdapter.dll

[jmangelo]

If you download the zipped release of Ninject 2.2 you get an
extensions folder containing the
CommonServiceLocator.NinjectAdapter.dll, however the same dll is not
included in the NuGet package.

Is there a separate and official NuGet package with that dll available?

[Remo Gloor]

No there isn't an offical one. You shouldn't use the service locator anyway. If you set up the IoC container correctly there isn't a reason for using it. All that should know about the IoC container is the composit root of your application. And there you can configure the container much more easily if you are not restricting you to the common service locator.

But someone uploaded one in case you really want to use it: http://www.nuget.org/List/Packages/CommonServiceLocator.NinjectAdapter.

[jmangelo]

Thanks, for the information, I'm aware of the debate around using the
ServiceLocator and that the code should be designed taking in
consideration a single composition root, however, the priority for the
moment is to get the code testable and the CSL answers that with an
amount of technical debt I'm willing to pay in the future.

I understand the reasoning in not including it the NuGet package since
you do not advocate the use of it, but I do not understand why it's
included in the *.zip then, since I think both packages should be
equivalent.

[Remo Gloor]

The nuget packages were introduced after the zip files. The CLS nuget package just didn't get enough priority to be added to the build scripts because I think there is no reason to use it anyway. There are still a lot other things that I give a lot more priority so that I won't add it soon. But if you or someone else from the community gives it enough priority to do this so that it is just a question of pulling it into the main repo and upload a nuget package I will add it.

--
You received this message because you are subscribed to the Google Groups "ninject" group.
To post to this group, send email to nin...@googlegroups.com.
To unsubscribe from this group, send email to ninject+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ninject?hl=en.

[jmangelo]

My concern was the following, I chose Ninject with the assumption that
even though it's not what you guys recommend to use, the CLS would be
supported by Ninject. Then when I realized that the CLS adapter is not
included in the NuGet package it made me feel that even though the CLS
is supported for the current version it may not be an future version,
which left me a bit worried thinking if I would not be better choosing
another IoC container.

[jlo]

There are unfortunately edge cases - unless I am missing something -
that require service location. They may have to do with poorly
designed dependencies we have to take - none the less when you need it
you need it.

One example is the ASP.Net Membership Provider. It is only
instantiated once in the ASP.Net life cycle - but in my case has a
dependency on a Repository. The Repository needs to be created on a
*per call* basis. So when I need it in a called method, I'm using
Service Locaiton to instantiate it.

I'm interested in how that could be accomplished without the service
locator.

Thanks for answering te question on where to find it - appreciated.

[Richard Wilburn]

If you use prism u will find that u need to use the common service locator if u want to shed yourself of unity. So the CommonServiceLocator is nessasary sometimes.

--
You received this message because you are subscribed to the Google Groups "ninject" group.

[pete]

Absolutely there are "edge" cases where CSL is the only option.

@Remo Gloor: what if you do not control the real composition root?
Like in a framework that has been designed without IoC in mind - not
to look far, say ASP.NET :)
Membership Provider is one example, Custom Certificate Validator is
another.
Also Ninject does not support constructor injection for ASP.NET
WebForms Page class, it only supports property injection and there's a
reason for that as well as there are real reasons to use CSL.

[pete]

I'm with you. CSL should be in the NuGet package.

[Remo Gloor]

CSL hase many disadvantages:
1. Hides dependencies
2. Supports only the least common denominator of all IoC containers
3. Adds a hard dependency to CSL to your assemblies

Therefore, I favor project specific factories with a container specific implementation which I consider part of the container configuration.  E.g. inject a IMyDependencyFactory containing a "IMyDependency CreateMyDependency(some, parameters)" method. Also see Ninject.Extensions.Factory. This solution does not have the above problems. In case of ASP.NET providers they need property injection of their dependencies at application initialization.

[Remo Gloor]

It will never be part of the Ninject nuget package. The majority of users isn't using it so there is no reason to have them forced to install CSL. We can discuss about a specific Ninject CLS package though. But I will not do it before the next version is released myself.

[Remo Gloor]

I'd always look for solutions that do not require the service locator pattern. Especially not CSL as it adds the additional problem that I can not take full advantage of my IoC container due to its restrictions.

E.g. in case of ASP:NET WebForms is can easily be solved using a module that injects the dependencies as it is done in the Web extension. This has the advantage that I have to create an ugly workaround in just one place (the module in this case) instead of using SL all over again. There isn't a general solution for this though and it has to be analized for each situation again how it is done best.

[pete]

Remo,

here you are talking about a specific problem which is often solved
(incorrectly) by using Service Location and that is not always using
all dependencies that might be heavy to create and inject.
Obviously many people resort to SL at that point, but here I'm with
you cause there's no reason to do SL in such situation - I use exactly
the same solution as you - inject a thin and cheap factory.
However what I'm trying to say is that there is no other option if you
do not control the Composition Root.

As for CSL it is just an implementation of Service Location pattern
that is compatible with many IoC containers - thus it has to be the
least common denominator and if you think about it it isn't that much
of a problem cause SL is very, very rarely needed and when you do need
it in most cases you won't need the extra features of a specific
container, you'll just need to get an implementation of a specific
interface.

Now if the least common denominator is a problem to you then you can
always create your own CSL very easily - I have one at the company I
work for - you just need to configure kernel and put it in a public
static property somwhere, ie. MyCompany.ServiceLocator.Ninject.Kernel
which would be of type IKernel
that's it - no more least common denominator

In my opinion the .NET community is guilty of making SL an anti-
pattern while it actually is not.

[pete]

A specific package is perfectly fine.