Why Ninject and not Unity?

[Gregory Kaidanov]

As i see it , the support in Unity is much bigger , and it's a
component included in microsoft tools , so what are the profound
advantages of the Ninject at the end of the day ?

[Markus Ewald]

Where have you got the information that "support for Unity is much bigger?"
Do you mean its user base? It's documentation?

Both projects follow their own design principles. I like Ninject better
because of its fluent configuration interface and because the design and
naming conventions are far more agreeable to me. Ninject 1.0 is one of
the few DI containers that can be configured to run on .NETCF 2.0 (and
therefore, through XNA, the XBox 360), which is important for me because
some of my projects target PC and XBox 360.

-Markus-

[J.R. Garcia]

I like it because it is very lightweight and easy to get started with. As Markus said, the naming conventions work better for me. It is the only IoC container that I was able to just get up and running without reading too much documentation. I read two pages out of the Ninject guide in less than 5 minutes and got it doing all I needed it to do in one of our projects in less than 20 minutes. I would also like to know what you mean by "much bigger".

The only argument I can see for Unity is that it is provided by Microsoft. The only stuff that I use that is provided by Microsoft is the .NET framework because I much prefer the other tools available. If you or your company has invested a lot of time into Microsoft tooling or if you are a "Microsoft-only" shop, then Unity may be a better fit.

J.R. Garcia
mrjohn...@gmail.com
http://johngarcia.emurse.com/

[Keyvan Nayyeri]

I like it because Simone had liked it before me ;-) But seriously, it’s always worthwhile to trust on other’s researches. I never spent much time to discover pros and cons of each framework, and just took a look at what others had said. What I extracted was that, Ninject is the best option for many circumstances, so I adapted it, and I’m completely satisfied.

 

Luckily, Ninject has a great team of developers who actively support the project and assisted me in 2-3 situations. IMHO it’s easy to use, has all the required features, and is completely reliable.

 

One point that I can tell you is that I’ve used Unity on a project and God knows how verbose the end code was. Ninject codes are comparatively simpler, shorter, and more readable!

 

Finally, add the point that Unit is provided by *Microsoft* and it means that it has a great potential to be a weak framework :-P

 

Keyvan Nayyeri

http://nayyeri.net

[Padcom]

I like Unity for the fact that it is a part of Microsoft world.
There's lots of examples, tutorials - that's where Microsoft is really
shining.
Where I dislike Unity is exactly where Ninject is best: in Unity you
need to declare all your dependencies with annotations, they need to
be public and it all makes the code very verbose and it couples the
code with Unity - using Ninject I can just provide the proper
constructor and have nothing else to pollute my code. In fact in my
business code I have no mentioning of Ninject whatsoever! I personally
love Ninject for that.

On Oct 21, 4:41 pm, "Keyvan Nayyeri" <nayy...@gmail.com> wrote:
> I like it because Simone had liked it before me ;-) But seriously, it's
> always worthwhile to trust on other's researches. I never spent much time to
> discover pros and cons of each framework, and just took a look at what
> others had said. What I extracted was that, Ninject is the best option for
> many circumstances, so I adapted it, and I'm completely satisfied.
>
> Luckily, Ninject has a great team of developers who actively support the
> project and assisted me in 2-3 situations. IMHO it's easy to use, has all
> the required features, and is completely reliable.
>
> One point that I can tell you is that I've used Unity on a project and God
> knows how verbose the end code was. Ninject codes are comparatively simpler,
> shorter, and more readable!
>
> Finally, add the point that Unit is provided by *Microsoft* and it means
> that it has a great potential to be a weak framework :-P
>
> Keyvan Nayyeri
>

>  <http://nayyeri.net/>http://nayyeri.net

>
> From: nin...@googlegroups.com [mailto:nin...@googlegroups.com] On Behalf
> Of J.R. Garcia
> Sent: Wednesday, October 21, 2009 6:05 PM
> To: nin...@googlegroups.com
> Subject: [ninject] Re: Why Ninject and not Unity?
>
> I like it because it is very lightweight and easy to get started with. As
> Markus said, the naming conventions work better for me. It is the only IoC
> container that I was able to just get up and running without reading too
> much documentation. I read two pages out of the Ninject guide in less than 5
> minutes and got it doing all I needed it to do in one of our projects in
> less than 20 minutes. I would also like to know what you mean by "much
> bigger".
>
> The only argument I can see for Unity is that it is provided by Microsoft.
> The only stuff that I use that is provided by Microsoft is the .NET
> framework because I much prefer the other tools available. If you or your
> company has invested a lot of time into Microsoft tooling or if you are a
> "Microsoft-only" shop, then Unity may be a better fit.
>
> J.R. Garcia

> mrjohngar...@gmail.comhttp://johngarcia.emurse.com/
>
> On Wed, Oct 21, 2009 at 5:35 AM, Gregory Kaidanov <2bher...@gmail.com>

[Miguel Madero]

Interesting answers. I didn't think before on most of those points, it just felt natural to like Ninject better, but wasn't sure exactly why, but I've to agree with every reason mentioned, specially that the names make a lot of sense.

A couple of times I have had to through the internals and I found the Unit Tests really useful to understand and as a great source of documentation, while doing some low level stuff with Unity/Object Build is way harder even with documentation.

Also debugging binding issues with the exception messages provided by Unity is a pain: On Unity I’ve had some really cryptic error like

Resolution of the dependency failed, type = "MyClass", …. Could not load type 'MyClass' from assembly '…’

MyClass isn’t even the dependency, is the type that I try to directly resolve from the container, the class is in the specified assembly, so the error message is obviously wrong. Knowing a bit of Unity this really means it failed for MyClass or any of it’s dependencies. Ninject’s error detail is super useful.

Error activating IMyClass3
No matching bindings are available, and the type is not self-bindable.
Activation path:
  2) Injection of dependency IMyClass3 into parameter myClass3 of constructor of type MyClass
  1) Request for MyClass

Suggestions:
  1) Ensure that you have defined a binding for IMyClass3.
  2) If the binding was defined in a module, ensure that the module has been loaded into the kernel.
  3) Ensure you have not accidentally created more than one kernel.
  4) If you are using automatic module loading, ensure the search path and filters are correct.

In my lame example, IMyClass3 is one of the dependencies of MyClass. The first line should be enough. The second is just providing an extra level of detail (no binding), the activation path, clearly tells you where is IMyClass3 required and we even get some nice suggestions and the first one is the most common one and  2, 3 and 4 are still provided for special cases.

I’m clearly in favor of Ninject over Unity for hundred more reasons, but this sole reason would be enough for me.

The way Ninject reports exception errors is clearly the result of several iterations and increments on the product. This is not something you would get the right time, but after using this in several projects someone (I imagine Nate), found the common causes of errors (suggestions) and a useful way of informing where the error really is.

BTW, the fact that it's developer by Microsoft, doesn't mean that it's supported by Microsoft. Each group has it's own priorities and budget and people assigned to different projects, specially in the case of P&P, people might be developing something today, release v1 and then move to something different. When is v2 coming out? I don't know, let's wait until we plan our budget again, assign other devs and start developing it. When are we going to fix bug 1023? I don't know, no one is currently supporting this product anymore.

I'm not saying this coudn't happen with other Open Source projects, just that the fact that it comes from Microsoft or P&P doesn't imply it's better supported.

--
Miguel A. Madero Reyes
www.miguelmadero.com (blog)
m...@miguelmadero.com

[Miguel Madero]

I forgot to ask. I started working with Ninject because it was the only IoC available for Silverlight (after using Object Builder in CAB, then Unity and Castle Windsor). I have to say it was thrilled to get away from the XML configuration.

Also, in a recent project that I worked with Unity, I wrote a lot of extension methods to create the bindings easily, making the methods less verbose.

[DavidHayden]

I really like Ninject and Autofac even though I don't get to use them
enough as my clients tend to be more Microsoft-based and therefore use
Unity and Enterprise Library.

I can give you some positives on Unity since I use it daily, however.

Unity is particularly nice if you use Enterprise Library. There are
Enterprise Library Extensions that auto-register themselves with Unity
which makes working and injecting the various blocks really easy.
Therefore, if you use a lot of the blocks in Enterprise Library, you
will probably want to use Unity.

Unity has two ways to register components: 1) XML and 2) Fluent
Interface. I hate XML, but it is very handy at times. The fact that
Unity gives you the choice as well as the ability to use both at the
same time is really nice in those circumstances where you can benefit
from the flexibility of XML to make configuration changes.

Unity also does not require you to use attributes on your classes. You
can achieve pure POCO using the XML or Fluent Interface alone. The
Fluent Interface is much more verbose than I personally prefer, but
very powerful. Attributes are purely optional and there just for your
convenience if you don't require POCO.

If you are big into AOP, I really love the seamless support for
various interception techniques in Unity as well as the ease of
building custom interceptors. Therefore if you are big into pulling
those cross-cutting concerns from your code and into reusable
interceptors, Unity gives you a number of interception options that
make it a breeze. Again, you can go full POCO with XML and Fluent
Interface techniques or use attributes if you find them more
convenient.

The patterns & practices team outsources their support to a
professional support organization that monitors their forums actively
so you shouldn't have a problem getting support. I haven't gone in
there in awhile, but the last time I looked they did a good job of
answering all the questions in a timely manner. Examples of using
Unity are everywhere so you probably don't even need to use the
forums.

Although P&P can appear to move slow on adding new functionality in
Unity and their other projects, I will say that the projects don't
stay in a never-ending "beta" which can happen with some OSS projects.
Therefore, in reality they probably do ship production, stable code
just as often as a lot of other OSS projects. However, they usually
only ship a major release and maintenance release each year and you
will have to wait for the next year for anything else to happen.
Thankfully they are not a "product team" at Microsoft or you would
have to wait for the next version of Visual Studio :)

So hopefully that provides a bit more balance on the opinions of
Unity, but alas, opinions will vary and I think it is always best to
try them out yourself and form your own opinions.

That being said, I can't say enough good things about other containers
like Autofac and Ninject. I use them any chance I can get. In fact my
whole reason for stumbling in here was to check on the status of
Ninject 2 to incorporate it into a new project. I have yet to use
version 2 and am looking forward to it. Any timeframe on when it may
actually be released? Not a requirement for my use as it appears to be
very stable, more of a curiosity.


Thanks,

Dave

On Oct 23, 7:43 am, Miguel Madero <m...@miguelmadero.com> wrote:
> I forgot to ask. I started working with Ninject because it was the only IoC
> available for Silverlight (after using Object Builder in CAB, then Unity and
> Castle Windsor). I have to say it was thrilled to get away from the XML
> configuration.
>
> Also, in a recent project that I worked with Unity, I wrote a lot of
> extension methods to create the bindings easily, making the methods less
> verbose.
>
>
>
>
>
> On Fri, Oct 23, 2009 at 10:40 PM, Miguel Madero <m...@miguelmadero.com> wrote:
> > Interesting answers. I didn't think before on most of those points, it just
> > felt natural to like Ninject better, but wasn't sure exactly why, but I've
> > to agree with every reason mentioned, specially that the names make a lot of
> > sense.
>
> > A couple of times I have had to through the internals and I found the Unit
> > Tests really useful to understand and as a great source of documentation,
> > while doing some low level stuff with Unity/Object Build is way harder even
> > with documentation.
>
> > Also debugging binding issues with the exception messages provided by Unity
> > is a pain: On Unity I’ve had some really cryptic error like
>
> > Resolution of the dependency failed, type = "MyClass", …. Could not load
> > type 'MyClass' from assembly '…’
>
> > MyClass isn’t even the dependency, is the type that I try to directly
> > resolve from the container, the class is in the specified assembly, so the
> > error message is obviously wrong. Knowing a bit of Unity this really means

> > it failed for MyClass or *any* of it’s dependencies. Ninject’s error