1, Spring introduction and hands-on experience

Keywords: Spring

1,Spring

1.1 INTRODUCTION

  • In 2002, the prototype of Spring framework, interface 21 framework, was launched for the first time.

  • Spring framework is based on interface21 framework. After redesign and constantly enriching its connotation, it released the official version of 1.0 on March 24, 2004.

  • Rod Johnson, the founder and famous author of spring framework, is hard to imagine rod Johnson's degree. He is a doctor from the University of Sydney, but it is not computer, but musicology.

  • Spring concept: it makes the existing technology easier to use. It is a hodgepodge and integrates the existing technology framework.

  • SSH: Struct2 + Spring + Hibernate

  • SSM: SpringMvc + Spring + Mybatis

Official website: https://spring.io/projects/spring-framework#overview

Official download address: https://repo.spring.io/release/org/springframework/spring

Github: https://github.com/spring-projects/spring-framework

<!-- https://mvnrepository.com/artifact/org.springframework/spring-webmvc -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>5.2.16.RELEASE</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.springframework/spring-jdbc -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>5.2.16.RELEASE</version>
</dependency>

1.2 advantages

  • Spring is an open source free framework (container)!
  • Spring is a lightweight, non intrusive framework!
  • Inversion of control (IOC), slice oriented programming (AOP)!
  • Support transaction processing and framework integration!

To sum up: Spring is a lightweight inversion of control (IOC) and slice oriented programming (AOP) framework!

1.3 composition

1.4 expansion

  • Spring Boot
    • A rapid development of scaffolding.
    • Based on SpringBoot, you can quickly develop a single microservice.
    • Agreement is greater than configuration!
  • Spring Cloud
    • Spring cloud is implemented based on SpringBoot.

Because most companies are now using SpringBoot for rapid development, the premise of learning SpringBoot is to fully master Spring and Spring MVC! The role of connecting the preceding and the following.

Disadvantages: after developing for too long, it violates the original concept! Configuration is very cumbersome, known as "configuration hell"

2. IOC theoretical derivation

What is IoC?

IoC, that is, Inversion of Control. What is control reversal? Control what? Reverse what?

Look at an example

Let's create an empty project first. The project structure is shown in the figure below:

dao layer

We create a user interface UserDao in dao, and then write three implementation classes userdaoimpl, userdaomongodbimpl and userdaomysqlimpl, corresponding to obtaining users from the default path, from MongoDB and from Mysql (this is only an example, and no specific implementation is written). The contents of each document are as follows:

UserDao.java

package com.luca.dao;

public interface UserDao {
    void getUser();
}

UserDaoImpl.java

package com.luca.dao;

public class UserDaoImpl implements UserDao{
    @Override
    public void getUser() {
        System.out.println("Get user data by default");
    }
}

UserDaoMongoDBImpl.java

package com.luca.dao;

public class UserDaoMongoDBImpl implements UserDao{
    @Override
    public void getUser() {
        System.out.println("MongoDB Get user data");
    }
}

UserDaoMysqlImpl.java

package com.luca.dao;

public class UserDaoMysqlImpl implements UserDao{
    @Override
    public void getUser() {
        System.out.println("Mysql Get user data");
    }
}

service layer

After the dao layer is implemented, we call the dao layer from the service layer.

UserService.java

package com.luca.service;

public interface UserService {
    void getUser();
}

UserServiceImpl.java

package com.luca.service;

import com.luca.dao.UserDao;
import com.luca.dao.UserDaoImpl;

public class UserServiceImpl implements UserService{
    UserDao userDao = new UserDaoImpl();

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

Test test

After completing the service layer, we can test under test:

MyTest.java

import com.luca.dao.UserDaoImpl;

public class MyTest {
    public static void main(String[] args) {
        UserDaoImpl userDao = new UserDaoImpl();
        userDao.getUser();
    }
}

When we run the test method, we can normally output "get user data by default", indicating that our program can run normally.

Expand the scene

In the above test method, we called the default method to obtain users. What if users want to obtain user information in MySQL?

We can modify userserviceimpl in the service layer. The UserDaoImpl of new needs to be changed to new UserDaoMysqlImpl. The new UserDaoMysqlImpl in the test method MyTest can meet the needs of new users.

But what if the user needs to modify MongoDB, or add Oracle or Redis? Each update requires modifying the code of the service layer, and the user also needs to modify the calling code. This method is too cumbersome and the maintenance cost is too high. In other words, such code coupling is too strong!

Another way

Let's organize the code in another way. In the service layer, we add a set method of UserDao:

UserServiceImpl.java

package com.luca.service;

import com.luca.dao.UserDao;

public class UserServiceImpl implements UserService{
    private UserDao userDao;

    public void setUserDao(UserDao userDao) {
        this.userDao = userDao;
    }

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

Accordingly, we modify the way of calling in the next MyTest:

import com.luca.dao.UserDaoImpl;
import com.luca.dao.UserDaoMongoDBImpl;
import com.luca.dao.UserDaoMysqlImpl;
import com.luca.service.UserServiceImpl;

public class MyTest {
    public static void main(String[] args) {
        UserServiceImpl userService = new UserServiceImpl();
        userService.setUserDao(new UserDaoImpl());
        userService.getUser();
        userService.setUserDao(new UserDaoMongoDBImpl());
        userService.getUser();
        userService.setUserDao(new UserDaoMysqlImpl());
        userService.getUser();
    }
}

We run the test method again and find that it can be executed normally. The three ways to obtain users are executed normally.

summary

We compare the following two ways:

In the first method, select where to get the user. This operation is performed by the service. The client (i.e. the above test method) sends instructions and the service executes it.

Changes have been made in the second method. The client can choose which method to use to obtain users (using setUserDao method), and the service layer is only responsible for unified processing.

The main difference: the second method transfers the power of selection and operation to the client rather than the service layer, which reduces the coupling of code logic. Here, the process of option transfer (control transfer) is__ Control reversal__ A way of.

It should be noted that this involves the use of object-oriented polymorphism (in the service, the corresponding getUser method of the object is called according to the different incoming objects).

My question

The above simple demonstration of the effect of control inversion, but I have a question?

We do implement the client self-service selection of user acquisition methods, but here the client directly calls the implementation classes of dao layer (UserDaoImpl, UserDaoMongoDBImpl, UserDaoMysqlImpl), which conflicts with our layered idea. This is one of my questions. I will find the answer in the later study of Spring.

Posted by sowmithrii on Mon, 29 Nov 2021 19:13:59 -0800