开发者

firsts steps with an IoC because I hit a wall, please explain the 'behind the scenes'

So I started this new project, and I was trying to incorporate all the new design principles I was reading about, namely trying to make things loosely coupled, testable, and following some patterns.

So I then ran into the issue of having to pass too many factories/managers into my classe开发者_StackOverflow中文版s constructor, which led me into Dependancy injection.

public class SomeClass
{
   public SomeClass(IDBFactory factory, IOrderManager orderManager, ....)
}

So if I use ninject, from what I understand, I would then bind a particular implementation to the class.

So what is going on behind the scenes?

NInject will, whenever I instantiate SomeClass, it will bind the implementation that I defined in the config file?

i.e.

I do:

ISomeClass sc = NInject.Get<ISomeClass>();

and ninject will do:

new SomeClassImpl(pass in all the implementaitons in the constructor)

correct?


I don't know NInject, but most DI Containers support Auto-Wiring, which works this way:

  1. When you request ISomeClass, it looks through its list of all registered types. Using this list, it discovers that the desired implementation of ISomClass is SomeClass.
  2. It will use SomeClass' constructor to create an instance (perhaps using Activator.CreateInstance), so it uses Reflection to figure out which paramters are required.
  3. For each paramameter, it looks at the type and repeats step 1-2 for each.

Thus, the process may be recursive, but in the end, you should end up with a fully populated object graph where all dependencies are satisfied.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜