IoC container-related responsibilities and major implementations
Inversion of control is designed for the following purposes:
-
Decoupling between task execution and implementation (Object-oriented design philosophy)
-
Focus on the implementation task of a module (the design purpose of the module on the task), that is, focus on the ultimate goal of the module or design, rather than its implementation
-
Release modules from contractual assumptions about how other systems do it, that is, to release the module, other systems need to know how it works, rather than depend on its contracts.
-
Prevent side effects when changing modules. In general, there may be some related side effects when a dependent change occurs, which may be more pronounced in the form of synchronous calls than in IoC.
IoC container responsibilities
-
Dependency handling, dependency lookup and dependency injection are the two main methods of dependency implementation
1.1 Dependent lookup is quite an active approach
1.2 Dependency injection, although there are active approaches, most of the work is done by the container.
Whether it is dependency lookup or dependency injection, the most important aspect of Spring is the handling of dependencies, such as how a dependency comes from and how it is returned to the client for processing. There are two major categories in Spring:
-
To look up according to some rule, such as by name or type
-
There are some corresponding ways to cast a type
-
Life cycle management
2.1 Container-related lifecycle. Containers have their own operations to start, stop, or pause, or terminate, or roll back
2.2 Life cycle of managed resources
Resources don’t necessarily mean Java Beans; they could be other resources, plain OLD POJOs, etc. For example, for some events in the Spring container, the listener corresponding to the event may not be the corresponding bean, but may be added externally. When the event occurs in the container, the context can be associated with the listener of some other events, and the listener neither belongs to the bean nor can be operated by dependency lookup or dependency injection. Spring’s beans can be used as a source for listeners, but not the only one, so managed resources are not necessarily Java Beans or so-called dependencies, but also include some externalized configurations, or externalized resources, such as XML Property files
-
configuration
3.1 Container configuration is to control the behavior of the container, such as when the container is started. Sometimes the container can be started regularly, such as the scheduled task. The scheduled task may have some sub-container operations, which is also a part of IoC. You just need to focus on the task you perform, not where it comes from.
3.2 Externalized configuration, mainly attribute configuration, also includes some XML configuration
3.3 Managed resources (Java Beans or other resources), such as thread pools, configured some external containers, such as Tomcat, dynamic containers, etc. For example, Spring Boot can influence the container by the Spring context in an embedded way, whereas Spring MVC influences the container by the context, where the effects are mutually reinforcing.
The main implementation of IoC containers
-
Java SE
1.1 Java Beans Dependency Lookup. Java Beans were introduced in Java 1.2 as part of the Java API to help manage Beans. Java Beans is intended not only for IoC containers, but also for guI-related extensions.
1.2 Java ServiceLoader SPI, the SPI mechanism was introduced in Java 1.6 and is widely used in NetBeans to load so-called components in this way.
1.3 Java Naming and Directory Interface (JNDI), which helps us find corresponding resources.
Naming refers to the IoC’s dependency search in the form of a name. Directory refers to a directory with a hierarchical structure and some nesting of the directory.
-
Java EE
2.1 Enterprise Java Beans (EJB), the traditional IOC implementation, EJB 1 or 2 version of the majority of the use of dependency lookup, from EJB 3.0, dependency injection and dependency lookup co-exist.
2.2 Servlets, a standard technology for the Web in Java, have some design patterns: For example, the design pattern of Model 2 is characterized by Java EE servlets to obtain database sources, thread pools, message services, etc., and also by JNDI in the Server container, EJB container, and Java EE container.