这些构造函数参数来自控件实例的这种反转？

Question

I'm working on an incomplete application in WPF/C#. Most of it is very well coded, though as I didn't know about Inversion of Control beforehand it puzzled me for a while. Now I think I've figured it out some, but some things still stump me.

Case in point: we have this great big class called CoreApplication that manages everything general. Among other things, it has a series of RegisterType instructions, among which

SharedObjects.InversionOfControl.RegisterType<IGoodClass, GoodClass>();

( SharedObjects being a static class that defines, among other things, a static IUnityContainer object named InversionOfControl , initialized with new UnityContainer() at declaration.)

Elsewhere in CoreApplication , there is an ICommand that includes the code

var goodClassForNavigation = (SharedObjects.InversionOfControl.Resolve<IGoodClass>()); 

Which, I understand, calls the constructor of GoodClass , since Register() linked IGoodClass and GoodClass and Resolve() was called with IGoodClass .

Fine. Now, going to GoodClass to understand what it does, I see that its constructor looks like this:

public GoodClass(CoreApplication coreApplication)
{
    this.coreApplication = coreApplication;
    // Other stuff happens
}

I've made sure that the parameter was duly instantiated; various properties and fields of it have the values I'd expect.

What I cannot understand is, where does this CoreApplication parameter come from?

I tried to look up the constructor in GoodClass 's base classes, but they have no explicit one.

Thanks to those who still are with me so far. What is happening? Where does the constructor take its parameter from? Is it from the class the constructor is called in? From something in SharedObjects.InversionOfControl ?

Answer 1

Simply put your DI framework does the heavy lifting:

1. you call Resolve(), a method of your DI framework
2. the DI framework now resolves IGoodClass to GoodClass
3. the DI framework analyses the constructor and sees that a parameter is needed
4. the DI famework now tries to resolve a parameter instance based on the parameter type, in your case CoreApplication
5. the DI framework creates and instance of CoreApplication
6. the DI framework now can create an instance of GoodClass by passing the resolved instance of CoreApplication to the constructor

The resolution process can be configured, for example with registration by convention .

I suggest you read the article Dependency Injection with Unity .