Important notes for SpringBoot

@SpringBootApplication

The SpringBoot project is added to the main class by default

We can think of @SpringBootApplication as a collection of @Configuration, @EnableAutoConfiguration, and @ComponentScan annotations.

  • @EnableAutoConfiguration: Enables SpringBoot automatic configuration
  • @ComponentScan: scans beans annotated by @Component (@service,@Controller). By default, the annotation scans all classes in the package in which that class belongs.
  • @Configuration: Allows registering additional beans or importing additional configuration classes in the Spring context

Spring Bean related

@Autowired

Automatically import objects into classes and automatically assemble beans

@Component,@Repository,@Service, @Controller

Identifies a class as a bean that can be used for auto-assembly with the @AutoWired annotation

  • Component: Generic annotation to mark any class as a Spring Component. If a Bean does not know which layer it belongs to, it can be annotated using the @Component annotation.
  • @repository: Corresponds to the persistence layer (Dao layer), which is used for database-related operations.
  • @service: corresponds to the Service layer, which involves complex logic and requires the Dao layer.
  • @Controller: corresponds to the Spring MVC control layer, which is mainly used to accept user requests and call the Service layer to return data to the front-end page.

@Scope

Declare the scope of the Spring Bean

There are four common Spring Bean scopes:

  • Singleton: A unique bean instance. Beans in Spring are singleton by default.
  • Prototype: Each request creates a new bean instance.
  • Request: Each HTTP request generates a new bean that is valid only within the current HTTP Request.
  • Session: Each HTTP request generates a new bean that is valid only for the current HTTP session.

Handles common HTTP request types

There are five common request types:

  • GET: Requests to GET a specific resource from the server. For example: GET /users (GET all students)
  • POST: Creates a new resource on the server. For example: POST /users (create students)
  • PUT: Updates the resource on the server (the client provides the updated entire resource). For example: PUT /users/12 (update student number 12)
  • DELETE: Deletes a specific resource from the server. For example: DELETE /users/12 (DELETE student number 12)
  • PATCH: Updates resources on the server (the client provides the changed properties, which can be regarded as partial updates). It is rarely used, so there are no examples here.
  • @GetMapping("users")Is equivalent to@RequestMapping(value="/users",method=RequestMethod.GET)
  • @PostMapping("users")Is equivalent to@RequestMapping(value="/users",method=RequestMethod.POST)
  • @PutMapping("/users/{userId}")Is equivalent to@RequestMapping(value="/users/{userId}",method=RequestMethod.PUT)
  • @DeleteMapping("/users/{userId}")Is equivalent to@RequestMapping(value="/users/{userId}",method=RequestMethod.DELETE)

The front and back ends pass values

@ PathVariable and @ RequestParam

@pathVariable is used to get path parameters, and @requestParam is used to get query parameters.

@RequestBody

It is used to read the body of a Request (POST,PUT,DELETE,GET) and its content-type is in application/ JSON format. After receiving the data, it will automatically bind the data to a Java object. The system uses HttpMessageConverter or a custom HttpMessageConverter to convert the JSON string in the body of the request into a Java object.

Note that a request method can only have one @requestBody, but can have multiple @RequestParam and @PathVariable. If your method must accept data with two @requestBodies, chances are your database design or system design is wrong!

Reading Configuration Information

  • @value: Reads simple configuration information
  • ConfigurationProperties: Reads the configuration information and binds it to the bean

Transaction @ Transactional

  • Applied to classes: When the @Transactional annotation is placed ona class, all public methods of that class are configured with the same transaction attribute information.
  • Applied to methods: When a class is configured with @Transactional and a method is configured with @Transactional, the method’s transaction overrides the Transactional configuration information of the class.

What are the attributes of the @Transactional annotation?

The propagation properties

Propagation Indicates the propagation behavior of the transaction. The default value is Propagation.REQUIRED.

  • Propagation.REQUIRED: Join the transaction if it exists, or create a new transaction if it does not exist. (That is, if methods A and B are annotated, the default propagation mode will merge the two methods’ transactions into one if method A calls method B internally.)
  • Propagation.SUPPORTS: Joins a transaction if it currently exists. If no transaction currently exists, it continues in a non-transactional manner.
  • Propagation.MANDATORY: If a transaction exists, it is joined. If no transaction currently exists, an exception is thrown.
  • Propagation.REQUIRES_NEW: Re-create a new transaction, and suspend the current transaction if it exists. Propagation.REQUIRED (A); Propagation.REQUIRES_NEW (B); [[email protected]_NEW] [[email protected]_NEW]
  • Propagation.NOT_SUPPORTED: To run in a non-transaction manner. If a transaction exists, it is suspended.
  • Propagation.NEVER: To run in non-transaction mode. If the transaction exists, an exception is thrown.
  • Propagation.NESTED: The result was the same as Propagation.

The isolation properties

Isolation: Isolation level of a transaction. The DEFAULT is Isolation.default.

  • TransactionDefinition. ISOLATION_DEFAULT: use a backend database default isolation level, Mysql default REPEATABLE_READ isolation level used Oracle READ_COMMITTED) isolation level used by default.
  • TransactionDefinition. ISOLATION_READ_UNCOMMITTED: the lowest isolation level, allowing the read has not yet been submitted data changes, may lead to dirty reads, phantom read or not repeatable read
  • TransactionDefinition. ISOLATION_READ_COMMITTED: allow read of concurrent transactions have to submit data, can prevent dirty reads, but phantom read or not repeatable read could still happen
  • TransactionDefinition. ISOLATION_REPEATABLE_READ: many of the same field to read the results are consistent, unless the data have been modified by itself affairs on their own, can prevent the dirty read and not repeatable read, but phantom read could still happen.
  • TransactionDefinition. ISOLATION_SERIALIZABLE: the highest isolation level, completely obey the ACID isolation level. All transactions are executed one by one so that interference between transactions is completely impossible. That is, this level prevents dirty reads, unrepeatable reads, and phantom reads. But this severely affects the performance of the program. This level is also not typically used.