Understanding of control inversion in asp.net (text + code) _ Practical Skills

The interpretation of the IOC was: "Inversion of control are a common characteristic of frameworks, so saying this, lightweight containers are s Pecial because they use inversion the control are like saying the My car is special because it has wheels. "

I would like to perform a personal elaboration of this concept to facilitate my understanding. Control reversal, from the literal point of view, is the control power from passive to active and passive, or passive to become active and passive. From this perspective, the IOC becomes very easy to understand.
For example: Your supervisor asks you to do one thing, there are so many processes at this time, the Supervisor orders you to do things (this time the initiative is in charge, you are passive)
You receive orders to do things (this time the subject is you, you are active, control is in your hands) you accomplish things (this time the subject is still you, control in your hand)
The report supervisor has done the work (the initiative is called into the supervisor's hands again)

The entire process has been completed a IOC, from the above can be seen, the basic idea of the IOC is the control of the conversion process.

Example of a code:
If you have Class A,class B, you can initialize a B within a, and call a gist of B.

Domethod public Class B

{public

void Domethod ()

{

///does somthing;

}

} public

C Lass A

{public

void Excute ()

{

b = new B ();

B.domethod ();

}

}

If you perform the following in the main function: A A = new A (); A.excute ();

From these two lines of code, there is actually an IOC process, a-->b-->a, and the key point of understanding is to B.domethod execution when the Excute is invoked inside a. Understanding the IOC, let's take a look at Di, from the above a to call B we can see that when you initialize an instance of a, you must also instantiate a B, which means that if B or B is not in doubt, a cannot be instantiated, which creates a dependency, that is, a dependent B, which is coupled from the design point of view. , it is obvious that it cannot meet the requirement of high cohesion and low coupling. This is the time to decouple, of course, there are many ways to decouple, and Di is one of them. Regardless of any decoupling essentials, it is not to say that A and B are completely not connected, but to make the implementation of this connection obscure, less straightforward, but easy to implement, and easy to expand, unlike the code above, directly new a B out. So why do we always associate the IOC with DI? Because the basic idea of Di is the IOC, and there is another way to embody the idea of IOC, that is service Locator, which seems to involve very little. In fact, these are derived from the Java, although I have not used Java for several years, which spring these will use the IOC, di as if they are tightly connected together.