Understanding of control inversion in asp.net, and understanding of asp.net Inversion

Understanding of control inversion in asp.net, and understanding of asp.net Inversion

IOC is interpreted as: "Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels."

I want to explain this concept one by one to facilitate my understanding. Control reversal, literally, means that control changes from passive to active, or passive to passive. From this perspective, IOC becomes very easy to understand.
For example, if your supervisor asks you to do one thing, there are so many processes and the supervisor instructs you to do things (at this time, the initiative is in charge, and you are passive) you receive commands to do things (at this time, the theme is you, you are active, and control is in your hands) You complete things (at this time, the theme is still you, and control is in your hands) report the supervisor to finish the task (the initiative is handed over to the supervisor)

The entire process above completes IOC once. From the above, we can see that the basic idea of IOC is the conversion process of control.

Example of code: if there is Class A and Class B, inside A, a B is initialized and A essentials of B is called.

DoMethod public Class B

{

Public void DoMethod ()

{

/// Do somthing;

}

}

Public Class

{

Public void Excute ()

{

B B = new B ();

B. DoMethod ();

}

}

Run the following command in the Main function: A a = new A (); a. Excute ();

From the two lines of code, there is actually an IOC process. a --> B --> a, the key point of understanding is that when A calls Excute internally, B. doMethod execution. After understanding IOC, let's look at DI again. We can see from the above that when A calls B, we can see that a B must also be instantiated when an instance of A is initialized, that is to say, if there is no question about B or B, A cannot be instantiated. This produces A dependency, that is, A depends on B. This dependency is coupling from the design perspective, obviously, it cannot meet the requirements of high cohesion and low coupling. At this time, decoupling is required. Of course, there are many essentials for decoupling, and DI is one of them. No matter what kind of decoupling essentials, it doesn't mean that A and B are completely unrelated, but that the implementation of this kind of association is concealed, not so direct, but easy to implement and easy to expand, unlike the code above, a new B is provided directly. Why do we always associate IOC with DI? It is because the basic idea of DI is IOC, and the essentials of reflecting IOC is Service Locator, which seems to involve very little. In fact, these are derived from java. Although I have not used java for several years, Spring will use IOC and DI as if they are closely connected.

Help me explain the meaning of control reversal in the image?

The technology in Spring is different from the general design implementation method.
Control Inversion (IoC = Inversion of Control)
IoC, in the vernacular, is the relationship between control programs by containers, rather than in non-traditional implementations, directly controlled by program code. This is also
That is, the concept of "control reversal": control is transferred from application code to external containers, and control is transferred.
USB interface Example:
A laptop is connected to a peripheral storage device through a pre-specified interface (USB). For a laptop,
Only the user-specified data is sent to the USB interface, and the path of the data is determined by the USB device currently connected. In the USB
Before the device is loaded, it is impossible for the laptop to predict which device the user will connect to on the USB interface.
The dependency between the slave nodes starts to form.
According to the above description about the dependency injection mechanism, at runtime (system boot, USB device loading ),
In Windows) to inject dependencies (laptops rely on USB devices for data access) into components (Windows
File Access component ).
Understanding:
In the traditional mode, classes are called directly, so there is a strong coupling degree, the dependency between programs is strong, and there are many problems involved in later maintenance.
IOC uses a configuration file (XML) to describe the relationship between classes, which is managed by containers, reducing the coupling between programs, you can modify the program through a simple configuration file.

Let's talk about spring's understanding of control reversal?

Control inversion is the same as dependency injection. I think we should focus on understanding what dependency is, and then control inversion and dependency injection will be realized, you can view UML-related books, focusing on the relationship between java objects. The so-called dependency is a relationship between objects. For example, object a depends on object B, then Class a will have class B References (simply put, Class a has such an attribute of Class B). That is to say, if object a wants to execute a complete function, you must establish a premise that Class B attributes in object a have been used as instances and have all the functions of Class B. Now you can understand what dependency injection is, as mentioned earlier, to complete a complete function of object a, you must first instantiate your class B attributes. In MVC mode, this phenomenon is very common. to simplify the instantiation, spring containers are generated. They can manage such frequent instantiation operations in a unified manner. That is to say, this kind of work should be put under control by the Spring containers themselves, that is, the control is reversed, one of the implementation schemes is to provide a setter Method for Class B in the above Class a. This method will be Pring container control.