"SSH Advanced path" Step by step refactoring container to implement spring framework--two schemes to solve the "intrusive" management of containers for components--active lookup and control inversion (ix)

Directory

"SSH Advanced path" Step by step refactoring container implementation Spring Framework-starting with a simple container (eight)
"SSH Advanced path" Step by step refactoring container to implement spring framework--two schemes to solve the "intrusive" management of containers for components--active lookup and control inversion (ix)
"SSH Advanced path" Step by step refactoring container implementation Spring Framework-configuration file + Reflection implementation IOC container (10) (not updated)
"SSH Advanced path" Step by step refactoring container implementation Spring Framework-completely encapsulated for a simple and flexible spring Framework (11) (not updated)

As for the IOC principle, we have written a blog post, "The Path to SSH" Spring's IOC is layered in-depth-why use ioc[instances to speak

Solution] (ii), comparative learning can be more profound understanding of the same problem.

Previous Blog "Advanced SSH Path" step by step refactoring container implementation Spring Framework -Starting from a simple container (eight), we want to remove the interface

The dependency on a specific implementation encapsulates a special not a simple container, and finally give everybody throws out a question: How do I make a component no longer dependent on a container? This article

Blog Main There are two solutions to solve this a question, and finally compare each advantages and disadvantages.

Service Locator

One solution is to use the service locator (Locator), or we can call active lookups. Service locators are used to encapsulate complex

Find logic while opening up a simple Find method, all components can delegate a lookup request to a service locator.

A service locator can be a simple class or a complex mechanism, such as Jndi. Different containers have different search mechanisms.

The following is a simple service locator:

public class Servicelocator {static{//The class is loaded once Container.init () is executed;} public static Object Getdao () {return container.getcomponent ("Dao4mysql");//return container.getcomponent (" Dao4oracle ");}}

to modify the lookup logic for Serviceimpl:

Import Com.tgb.container.servicelocator;import Com.tgb.container.dao.dao;import Com.tgb.container.service.Service ;p Ublic class Serviceimpl implements Service {//Find the required interface from the server locator private DAO DAO = (Dao) Servicelocator.getdao ();;  @Overridepublic void Servicemethod () {Dao.daomethod ();}}

UML Class Diagrams:

The Serviceimpl-to-container dependency line was previously added to the Servicelocator, and the components were no longer directly dependent on the container, implementing a "non-intrusive

-Type "management.

Control Inversion (IoC)

The second solution is to use control inversion, we give control to the container, in the runtime is determined by the container to the specific implementation of the dynamic "inject" to

The object that invokes the class.

IOC is a common design principle, and DI (Dependency injection) is a specific design pattern. There are three ways to inject dependency, and we are using setter injection.

To modify the service interface:

Import Com.tgb.container.dao.dao;public interface Service {//Add method to inject interface public void Setdao (dao dao);p ublic Void Servicemethod ();}

Modify Serviceimpl:

Import Com.tgb.container.dao.dao;import Com.tgb.container.service.service;public class Serviceimpl implements Service {private DAO DAO;  Dependency Injection public void Setdao (dao dao) {this.dao= dao;} @Overridepublic void Servicemethod () {Dao.daomethod ();}}

to modify the initialization method of the container class:

Import Java.util.hashmap;import Java.util.map;import Com.tgb.container.dao.dao;import Com.tgb.container.dao.impl.dao4mysqlimpl;import Com.tgb.container.service.service;import Com.tgb.container.service.impl.serviceimpl;public class Container {private static map<string, object>  Components;private Container () {}/** * Initialize container */public static synchronized void init () {if (components = = NULL) {components = new hashmap<string, object> ();//write a read config file class, according to read the configuration file, reflect the corresponding class//Reflection good class after the dependency management, to the corresponding attribute to inject the corresponding class DAO Dao4mysql = new Dao4mysqlimpl (); Components.put ("Dao4mysql", dao4mysql); Service service = new Serviceimpl ();  Components.put ("service", service);//Container Maintenance dependency Service.setdao (Dao4mysql);}} /** * Find Component *  * @param ID * @return */public static Object getcomponent (String ID) {return components.get (ID);}}

UML Class Diagrams:

The dependency line from Serviceimpl to container can be wiped out directly!

Setter injection is easy to use, but there are security issues. After the first injection, it is possible to call the setter method again, altering the original dependency.

this unintentional modifications to dependencies can have unpredictable consequences. Therefore, a security check mechanism is required.

Contrast

The solution component no longer relies on containers, and we used two scenarios: Service locator and control inversion.

1. Use The Service locator finds the component, which is a master the behavior of the dynamic lookup. This lookup has one drawback: the component needs to know how to find the resource. Component and container dependencies become dependencies on components and service locators.

2. Then, we used control inversion, which is a passive lookup behavior. The container proactively pushes the resource to the component, and the component accepts the resource in an appropriate way. reverse the Resource acquisition direction, which is the famous IOC (control inversion).

from the class diagram we can see that the container needs to know the various components, the coupling degree of the container and the component is still very high, the next post "SSH Advanced Road"

Step-by-step refactoring container Implementation Spring Framework-configuration file + Reflection implementation IOC container (10), we use configuration file + reflection to further reduce coupling.

Source Download

"SSH Advanced path" Step by step refactoring container to implement spring framework--two schemes to solve the "intrusive" management of containers for components--active lookup and control inversion (ix)