On the principle of spring in SSH framework

  • 2020-05-30 20:05:11
  • OfStack

In the ssh project, there is a clear division of labor. The role of spring is equivalent to connecting struts and hibernate. It is to put the features, methods and action of two unrelated frameworks into the configuration file of spring so that they can establish a relationship. Take the chief of every branch. But they don't know this, they are under the command of spring, his task is just to do his own thing.

The advantage is the task structure is clear, struts management shows and what to do, only hibernate only CARES about what to do, and spring is equivalent to the leadership, so 1 cut classes are created to spring factory, this is a kind of good development pattern, embodies the 1 kind of programming ideas, the biggest benefit is structured, easy to maintain, as the project appear problem, only change the spring file, but not you complex program to discover who is who in the call.

ssh framework, in short, in general are used for decoupling and struts management presentation layer, spring management business logic layer and persistence layer hibernate management, 3 framework is not associated with each other, called spring hibernate, spring struts calls for method calls, advantage spring geared to the needs of the design of the interface, as long as your interface and same impl change in the configuration file configuration, so after implementation of the project, can realize soft coding, The configuration file used for remote invocation directly modifies the configuration file to invoke the already written class to add functionality.

The following examples are used to understand the concepts involved in Spring, such as solution container, DI, IOC, coupling and decoupling, as well as the most basic and core usage methods of Spring.

1. Spring container

The Spring container is responsible for object instantiation and object lifecycle management, and objects managed by Spring are called Bean.

For example, if there is an Soldier class that needs to be managed by the Spring container, let's write the class first


package com.hb;

public class Soldier {

  private String name;

  public String getName() {

    return name;

  }

  public void setName(String name) {

    this.name = name;

  }

}

Add the following configuration to the Spring configuration file

< < /SPAN > bean id="s1" class="com.hb.Soldier" > < / < /SPAN > bean >

Initialize the Spring container


public class Test {

  public static void main(String[] args) {

ApplicationContext context = new

ClassPathXmlApplicationContext("applicationContext.xml");

  }

}

Get an object instance from the Spring container


Soldier s1 = (Soldier) context.getBean("s1");

Spring creates objects by default using singletons. You can change the configuration to create something else. This property is Scope, called the scope or lifecycle, and has values of singleton (singleton, default), prototype (one new instance at a time), and so on.


 <</SPAN>bean id="s1" class="com.hb.Soldier" scope="prototype"></</SPAN>bean>

2. The injection methods are setter injection, construction injection, interface injection (no need to master). Setter injection is recommended.

Setter injection:

There is a property name in the Soldier class, how to change the value of name to "RANBO" ? when creating Soldier;

The configuration is as follows:


<</SPAN>bean id="s1" class="com.hb.Soldier">

<</SPAN>property name="name" value="RANBO"/>

</</SPAN>bean>

In this way, the name property of the Soldier object created has a value. The test code:


public static void main(String[] args) {

ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

Soldier s1 = (Soldier) context.getBean("s1");

System.out.println(s1.getName());

}

Construction injection:

Let's first modify the Soldier class and add a constructor to it:


package com.hb;

public class Soldier {

  private String name;

 

  public Soldier(String name) {

    this.name = name;

  }

 

  public String getName() {

    return name;

  }

}

The configuration is as follows:


<</SPAN>bean id="s1" class="com.hb.Soldier">

<</SPAN>constructor-arg value="RANBO"></</SPAN>constructor-arg>

</</SPAN>bean>

The test results were the same as above.

3. Rely on

When A objects use the methods of B objects, A becomes dependent on B and is called A dependent on B. In the following example, the Soldier class relies on the HandGun class.


package com.hb;

 

public class Soldier {

  

  public void fight(){

    HandGun handGun = new HandGun();

    handGun.killEnemy();

  } 

}
 

 

package com.hb;

 

public class HandGun {

  

  public void killEnemy(){

    System.out.println(" Gun kill ");

  }

}

When HandGun changes, Soldier must be modified accordingly. At the same time, when Soldier needs to use OtherGun, code must be rewritten, resulting in a low degree of code reuse.

When the dependencies between objects are strong (coupling), the program code will be rigid, which is not conducive to later maintenance and extension. Reducing dependencies between objects is called decoupling. Spring is a good solution to this problem.

4. Inversion of control (Inversion of Control, IOC for short) and dependency injection (Dependence Inject, DI for short)

We use setter injection method of Spring to solve the coupling problem between HandGun and Soldier. Modify the code of Soldier to define HandGun as the property of Soldier and provide the setter method:


package com.hb;

 

public class Soldier {

  private HandGun handGun;

  

  

  public void setHandGun(HandGun handGun) {

    this.handGun = handGun;

  }

  

  public void fight(){

    handGun.killEnemy();

  } 

}

Configuration is as follows


public class Test {

  public static void main(String[] args) {

ApplicationContext context = new

ClassPathXmlApplicationContext("applicationContext.xml");

  }

}

0

At this point, we have reduced some of the dependencies on HandGun and Soldier, at least without having to instantiate HandGun ourselves in Soldier. However, the problem is not completely solved. The HandGun class can still be seen in Soldier, so we use the interface to further improve the code:


public class Test {

  public static void main(String[] args) {

ApplicationContext context = new

ClassPathXmlApplicationContext("applicationContext.xml");

  }

}

1

Configuration is as follows


public class Test {

  public static void main(String[] args) {

ApplicationContext context = new

ClassPathXmlApplicationContext("applicationContext.xml");

  }

}

2

Testing:


ApplicationContext context = new

ClassPathXmlApplicationContext("applicationContext.xml");

Soldier s1 = (Soldier) context.getBean("s1");

s1.fight();

So far, we have solved the coupling problem between HandGun and Soldier very well with Spring. Soldier class no longer has HandGun, Soldier only depends on the interface, but Soldier finally USES HandGun. Why? Spring manages individual objects here, as well as dependencies between objects, Soldier and HandGun. Originally, Soldier controlled the instantiation of HandGun, which was transferred to the Spring container for control. Here, a transfer of control occurred, which is called inversion of control (Inversion of Control, IOC for short). When Soldier needs HandGun, Spring will automatically inject HandGun objects into Soldier, which is dependency injection.


Related articles: