CODEWITHSUNDEEP
c#dependency-injectionninject
Stacker
Stacker

Reputation: 8237

Ninject and configuration

I used to use Castle as an IoC but I had a problem using Nhibernate/Castle(IoC) in the same project so i moved to Ninject. Now to get to the question, I have this class:

class CustomModule :  NinjectModule
{
   public override void Load()
   {
       Bind<Interfaces.ICafe>().To <Concrete.Tea>();
   }
}

Concrete is a separate project and Interfaces.ICafe is a different project. With Castle I used to give a developer the interfaces DLL and ask him to implement a new concrete implementing that interface and then configure that with the app.config, so no matter what class name he implements it still works because he has to write that in the app.config, so if he made it like Concrete.Coffee it would still work.

But with Ninject he has to make a concrete with the same class name "Tea" in order to make it work otherwise it wouldn't work because it is hard coded.

I'm new to Ninject and i know there is probably something I'm missing ?

Upvotes: 0

Views: 3974

Answers (3)

Richard Nienaber
Richard Nienaber

Reputation: 10564

I haven't used it but there are release candidates for Ninject.Extensions.Xml which allows you to setup your mappings in xml. However I have to agree with Paul and I would generally shy away from doing it this way. There's also Ninject.Extensions.Conventions which might be what you're after.

Upvotes: 0

Ian Davis
Ian Davis

Reputation: 3858

If you want to avoid referencing the concrete implementation, you can use the conventions extension to load the implementation at runtime.

-Ian

Upvotes: 1

Paul
Paul

Reputation: 36319

There's been a general trend (among the folks I know or follow, anyway) to moving IoC bindings into code and out of XML. Mostly b/c you gain intellisense and runtime feedback of screw-ups. So, yes, you have to have a reference to Concrete.Tea if you're going to do things that way.

Upvotes: 1

Related Questions