Options for wiring dependencies with NInject

With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?

Can they be defined in an XML configuration file?

Or does it have to be done via code?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml

You can do a lot more powerful binding in code though.

Method 2

Ninject doesn’t have XML configuration, sorry but I can’t provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:

Free yourself from XML

Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.

Method 3

The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.

If we had xml config I wouldn’t need reference at all, and wouldn’t have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!

Or maybe there is a possibility to achieve this using Ninject?

Method 4

What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you’re thinking in order to get a better answer [that you can acccept :P].

You need to split the concerns of:

  1. known object wiring (DI)
  2. configuration – generally you’ll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
  3. plugins / unknown object wiring (MEF?)

In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x