mirror of
https://gitee.com/many2many/java-web.git
synced 2025-01-11 22:50:54 +08:00
202 lines
8.7 KiB
Markdown
202 lines
8.7 KiB
Markdown
## Spring Boot实践
|
||
|
||
### Spring Boot – 架构
|
||
|
||
Spring Boot应用的层次结构
|
||
|
||
在Spring Boot项目中，典型的分层架构包括表现层（Presentation）、业务层（Business）、持久层（Persistence）和数据库层（Database）。合理划分各层职责，可以有效管理业务逻辑和数据访问，提高代码的清晰度和可测试性。
|
||
|
||
|
||
|
||
#### 表现层
|
||
|
||
表现层是Spring Boot架构的最顶层。它包含视图，即应用程序的前端部分。它处理HTTP请求并执行身份验证。负责将JSON字段参数转换为Java对象，反之亦然。一旦完成请求的身份验证，它就会将请求传递给下一层，即业务层。
|
||
|
||
在前后端完全分离的情况下，Spring Boot的表现层的实现主要涉及如下内容：
|
||
|
||
RESTful API：
|
||
> 使用`@RestController`注解的控制器类来处理HTTP请求，返回JSON格式的数据。这些API通常用于与前端JavaScript框架（如React、Vue.js或Angular）交互。
|
||
|
||
跨域资源共享（CORS）：
|
||
> 为了支持前端应用从不同的域名发送请求，需要在Spring Boot应用中配置CORS。可以通过在控制器方法上使用`@CrossOrigin`注解或者全局配置CORS来实现。
|
||
|
||
身份验证和授权：
|
||
> 使用Spring Security来处理用户身份验证和授权。Spring Security提供了多种方式来保护RESTful API，包括基于表单的登录、JWT（JSON Web Tokens）、OAuth2等。
|
||
|
||
异常处理：
|
||
> 使用`@ControllerAdvice`和`@ExceptionHandler`注解来全局处理异常，确保API返回统一的错误信息格式。
|
||
|
||
请求和响应拦截：
|
||
> 使用`HandlerInterceptor`或`Filter`来拦截请求和响应，可以用于日志记录、性能监控、请求校验等。
|
||
|
||
静态资源处理：
|
||
> Spring Boot默认支持静态资源的处理，可以将HTML、CSS、JavaScript等文件放在`src/main/resources/static`目录下，Spring Boot会自动配置好静态资源的访问路径。
|
||
|
||
模板引擎：
|
||
> 尽管在前后端分离的架构中不常用，但Spring Boot仍然支持模板引擎（如Thymeleaf、FreeMarker等），用于渲染HTML页面。
|
||
|
||
|
||
#### 业务层
|
||
|
||
业务层包含所有的业务逻辑。在spring boot应用中，在Spring Boot应用中，业务层（也称为服务层或应用层）的实现主要涉及以下几个方面：
|
||
|
||
服务类（Service Classes）：
|
||
> 这些类包含实现业务逻辑的方法，它们通常作为领域模型（即实体层）和控制器（表现层）之间的中介。
|
||
|
||
业务逻辑封装：
|
||
> 业务层负责封装核心业务逻辑，确保业务规则的一致性和正确性，以及数据的完整性。
|
||
|
||
验证（Validation）：
|
||
> 业务层负责对输入数据进行验证，确保它们符合业务规则和约束。这通常通过使用JSR 303/JSR 380注解（如`@NotNull`、`@Size`、`@Valid`等）来实现。
|
||
|
||
授权（Authorization）：
|
||
> 在业务层中，可以进行更细粒度的授权检查，以确保用户只能访问他们被授权的资源或执行他们被授权的操作。
|
||
|
||
事务管理（Transaction Management）：
|
||
> 业务层常常涉及到数据库事务的管理，Spring Boot通过声明式事务管理（使用`@Transactional`注解）来简化事务的控制。
|
||
|
||
异常处理：
|
||
> 业务层需要处理业务逻辑中可能发生的异常，并将其转换为对用户更友好的错误信息或业务异常。
|
||
|
||
业务流程协调：
|
||
> 业务层负责协调多个业务操作的执行顺序，实现复杂的业务流程。
|
||
|
||
数据转换：
|
||
> 业务层可能需要将领域模型（Domain Models）转换为DTOs（Data Transfer Objects），以适配前端的数据需求。
|
||
|
||
集成外部服务：
|
||
> 业务层可以集成和调用外部服务或API，如支付网关、邮件服务、第三方数据接口等。
|
||
|
||
业务决策：
|
||
> 业务层包含业务决策逻辑，这些逻辑基于业务规则和策略来指导应用程序的行为。
|
||
|
||
缓存管理：
|
||
> 业务层可以负责缓存策略的实现，以提高应用程序的性能。
|
||
|
||
异步处理：
|
||
> 对于耗时的业务操作，业务层可以实现异步处理机制，如使用Spring的`@Async`注解。
|
||
|
||
消息队列：
|
||
> 业务层可以与消息队列（如RabbitMQ、Kafka）集成，以实现异步消息传递和处理。
|
||
|
||
#### 持久层
|
||
|
||
持久层包含所有的数据库存储逻辑。它负责将业务对象转换为数据库行，反之亦然。在Spring Boot应用中，持久层的实现主要涉及以下几个方面：
|
||
|
||
数据访问对象（DAO）：
|
||
> DAO负责与数据库进行交互，执行CRUD操作。通常使用`@Repository`注解来标记DAO类。
|
||
|
||
实体类
|
||
> 数据库实体类是持久层与数据库交互的桥梁。它们定义了数据库中的表和字段，并映射为Java对象。
|
||
|
||
ORM框架：
|
||
> Spring Boot支持多种ORM框架，如JPA、Hibernate、MyBatis等。这些框架可以帮助开发者更方便地进行对象关系映射。
|
||
|
||
数据转换：
|
||
> 持久层可能需要将实体对象转换为数据库行，反之亦然。ORM框架通常会自动处理这些转换，但有时也需要手动编写转换逻辑。
|
||
|
||
查询优化：
|
||
> 持久层需要关注查询性能，可以通过索引优化、查询缓存、批量操作等方式来提高查询效率。
|
||
|
||
### 数据库层
|
||
|
||
数据库层包含所有类型的数据库，如MySQL、MongoDB等。在Spring Boot应用中，数据库层的实现主要涉及以下几个方面：
|
||
|
||
数据库选择：
|
||
> 根据应用的需求选择合适的数据库，如关系型数据库（MySQL、PostgreSQL）或NoSQL数据库（MongoDB、Cassandra）。
|
||
|
||
数据模型设计：
|
||
> 设计合理的数据模型，包括表结构、索引、外键等，以满足业务需求并优化查询性能。
|
||
|
||
数据迁移：
|
||
> 使用Flyway或Liquibase等工具进行数据库迁移，确保数据库结构的一致性和版本控制。
|
||
备份和恢复：
|
||
> 定期备份数据库，确保数据的安全性。在发生故障时，可以快速恢复数据。
|
||
|
||
#### 流程架构
|
||
|
||
|
||
|
||
- 客户端发出 HTTP 请求（GET、PUT、POST 等）
|
||
- HTTP 请求被转发到 Controller。控制器映射请求。它处理句柄并调用服务器逻辑。
|
||
- 业务逻辑在 Service 层执行。Spring Boot 对通过 Java Persistence Library （JPA） 映射到 spring boot 模型类的数据库数据执行所有 logic 。
|
||
- 控制器返回 HTTP 响应(Json或HTML)。
|
||
|
||
### Spring Boot – 代码结构
|
||
|
||
https://www.geeksforgeeks.org/spring-boot-code-structure/
|
||
|
||
Spring Boot Projects 没有特定的布局或代码结构。但可以遵循的一些最佳实践。
|
||
|
||
建议将 Main Application 类放在根包中，并带有 @SpringBootApplication、@ComponentScan 或 @EnableAutoConfiguration 等注释。它允许 Spring 扫描根包和子包中的所有类。
|
||
|
||
常用的构建Spring Boot 项目的两种代码结构：
|
||
- 按功能划分的结构
|
||
- 按层划分的结构
|
||
|
||
**结构1：按功能**
|
||
|
||
在这种结构中，与某个功能相关的所有类都放在同一个包中。按特征划分的结构外观如以下：
|
||
|
||
```text
|
||
com
|
||
+- lk
|
||
+- demo
|
||
+- MyApp.java
|
||
|
|
||
+- customer
|
||
| +- Customer.java
|
||
| +- CustomerController.java
|
||
| +- CustomerService.java
|
||
| +- CustomerRepository.java
|
||
|
|
||
+- order
|
||
+- Order.java
|
||
+- OrderController.java
|
||
+- OrderService.java
|
||
+- OrderRepository.java
|
||
|
||
```
|
||
|
||
这种结构的优点如下：
|
||
* 找到要修改的类很容易。
|
||
* 通过删除特定的子包，可以删除与某个功能相关的所有类。
|
||
* 测试和重构很容易。
|
||
* 功能可以单独发布。
|
||
|
||
**结构2：按逻辑层次**
|
||
|
||
可以将项目划分为控制器层（接口层）、服务层、存储库层等层。
|
||
所有控制器都可以放置在 Services Package 下的 controllers Package 和 Services 中，所有实体都可以放置在 Domain 或 Model 等下。
|
||
```text
|
||
com
|
||
+- lk
|
||
+- demo
|
||
+- MyApp.java
|
||
|
|
||
+- domain
|
||
| +- Customer.java
|
||
| +- Order.java
|
||
|
|
||
+- controller
|
||
| +- OrderController.java
|
||
| +- CustomerController.java
|
||
|
|
||
+- service
|
||
| +- CustomerService.java
|
||
| +- OrderService.java
|
||
|
|
||
+- repository
|
||
+- CustomerRepository.java
|
||
+- OrderRepository.java
|
||
|
||
```
|
||
|
||
层次结构的优点：
|
||
|
||
* **清晰的职责划分**：每个层都有明确的职责，便于理解和维护。
|
||
* **模块化设计**：不同层的代码可以独立开发和测试，提高了代码的可复用性和可测试性。
|
||
* **易于扩展**：新增功能时，可以按照既定的层次结构进行扩展，减少了代码的修改范围。
|
||
* **代码组织有序**：代码按照功能层次组织，便于团队成员快速定位和理解代码。
|
||
|