IOC (inversion of control) or dependency injection di (dependency injection). If an interface has two implementation classes, these two implementation classes are used in the implementation process. If IOC is used, only one interface type can be registered. How can I ensure that IOC imports instances of different classes when appropriate? This is a question that suddenly occurred to me. I hope you can help me solve it!
The so-called IOC (control inversion) or dependency injection refers to handing over the class you designed to the system for control, rather than controlling it within your class. A change in control is called control inversion. I personally think that IOC is the best time to use it when an interface has multiple implementation classes and the interface may be extended. We use abstract interfaces to isolate the dependencies between users and specific implementation classes? Who depends on who? We need to clearly understand this relationship to better understand how to use IOC. I think the user depends on the specific implementation. IOC indicates dependency injection, but which one is dependent on? Class { IB _ B; Public () { _ B = new impb (); // In the call implementation class impb, the method defines a variable of this type using the interface definition method, which adopts the interface definition method, it can be called interface-oriented programming, which is now a very common method. Instead of abstract programming, API-oriented programming is adopted. } } Class impb: IB { // Specific implementation class } Class impc: IB { // C implementation } However, if you use the IOC method, you only need to input the required parameters in the constructor of. This will cause the two implementation classes mentioned above. In addition, I want to raise another question: how to inject values when an implementation class inherits from two interfaces? Several Concepts about IOC: Service: automatic assembly of components The so-called service is a series of interfaces, the interface agreed to the service, so that the specific implementation of the random replacement implementation interface will not use the serviceCodeMake any changes. Service-oriented programming = interface-oriented programming? Components: A component is reusable.ProgramA unit is an implementation class that implements a specific interface and only implements the interface. A component is a class that implements a service interface. Specific implementation class. Automatic Assembly(Auto wiring): The dependency between components is automatically managed by the container. It automatically injects the required instance in some injection mode when specific implementation is required. IOC is also a design pattern used to coordinate the combination between components. The migration of programs and good component decoupling are added. You do not need to use new in the implementation class to instantiate the object, avoiding coupling between component classes and changing the internal code implementation of the program when you need to change the specifics. IOC solves this problem. It manages the relationship between components by referring to external containers in the program, that is to say, the container dynamically injects dependencies between components into the components during running. The implementation of inter-program relations is managed by external containers. This is the so-called Hollywood law. Don't look for me, I will look for you. Note the following:Focus classification (SOC)This should be the initial objective of IOC, to achieve separation of focus, through the decomposition of the program, the program into a functional point, and then ensure that each functional point is not directly related to each other. This is the principle of separation of concerns. When IOC transfers control to itself, it actually removes the Actual dependency between components and directly coupling components (that is, implementation classes. The basic principle of separation of concerns is achieved. There is also a design principle called the Aspect-oriented programming principle (AOP), which is a vertical view of program functions. I personally think IOC is a theory, and Di is a specific implementation method, Now let me ask a question? Why do we have to register autofac or IOC in the application_start Method for component decoupling? A: We know that both Asp.net web form and MVC run on. NET Framework and control the whole process from page request to page response through IIS. Every request from the beginning to the final response (also called the Declaration cycle) is controlled by the Asp.net worker process, because we cannot directly control the process, therefore, we want to avoid the possibility of injection throughout the lifecycle. In this case, we can only inject before the lifecycle begins. A request is processed by IIS from entry to response, and the ihttpmodule pipeline can be used for dependency injection. This explains why we can only register before the program starts. Autofac is a framework closely integrated with C # in IOC theory. It provides incomparable advantages over other frameworks: 1. Use C # Generic 2. You can easily register Asp.net MVC Controller 3. Support for C # Lambda expressions and perfect support for LINQ 4. It is non-invasive and can be used to manage the instance and claim cycle of the object at runtime. 5. Lightweight Framework Simple use of autofac: 1. The registration type is simple. autofac can run normally without any xml configuration. Of course, autofac can also be configured through the xml configuration file. Public void applicationstart () { VaR builder = new containerbuilder (); // create an autofac container instance for managing the registration class // Register the types it can manage for the container. // The Register Method of builder. Register... builder can be registered in multiple ways. // In fact, it is necessary for us to have a detailed understanding of these register methods. After all, each method can find a specific place to use. // Builder. Build (); // generate a specific instance // The following describes how to change the injection method using MVC extension. VaR Container = builder. Build (); Dependencyresolver. setresolver (New autofac. Integration. MVC. autofacdependencyresolver (container); // modified the injection method in MVC. } 2. Use constructor injection in homecontroller Public class homecontroller { Private Inet _ net; Public homecontroller (Inet net) // interface definition constructor Injection { _ Net = net; // we can see through single-step debugging at runtime that net is actually a specific instance for implementing the interface inet. The premise is that autofac has been correctly registered and configured correctly. } Public actionresult () { VaR result = _ net. getall (); // call a specific method of a specific class to return the result Return view (result); // pass the value } } In this way, we can use autofac as a component in the project to manage our programs and transfer control. To sum up, IOC essentially transfers the user's control to an independent component (autofac), achieves decoupling between components through various injection methods, and achieves separation of concerns. Autofac is very simple to use, so I will not give an example. I just explain the background of IOC. I have never seen autofacSource codeI don't know if my understanding is correct. If there is a mistake, please point it out. I will correct it actively. Thank you. IOC is just a means, not an aim, not something we should consider when designing the architecture. It is just a technique we adopt in implementation, of course, there are other methods that can achieve similar results, and many such components can achieve this effect. Our ultimate goal is to achieve separation of concerns and the minimum coupling between components.
