mirror of
https://gitee.com/many2many/java-web.git
synced 2025-01-11 14:40:55 +08:00
114 lines
3.7 KiB
Markdown
114 lines
3.7 KiB
Markdown
|
## Spring Boot实践
|
|||
|
|
|
|||
|
|
### Spring Boot – 架构
|
|||
|
|
|
|||
|
|
Spring Boot 层
|
|||
|
|
Spring Boot 由以下四层组成：
|
|||
|
|
|
|||
|
|
表示层 - 身份验证和json翻译
|
|||
|
|
业务层 - 业务逻辑、验证和授权
|
|||
|
|
Persistence Layer – 存储逻辑
|
|||
|
|
Database Layer – 实际数据库
|
|||
|
|
|
|||
|
|
图 1 – Spring Boot 的层
|
|||
|
|
|
|||
|
|
1. 表示层
|
|||
|
|
|
|||
|
|
表示层是 Spring Boot 体系结构的顶层。它由 View 组成。即应用程序的前端部分。它处理 HTTP 请求并执行身份验证。它负责将 JSON 字段的参数转换为 Java 对象，反之亦然。一旦它执行了请求的身份验证，它就会将其传递到下一层。即业务层。
|
|||
|
|
|
|||
|
|
2. 业务层
|
|||
|
|
|
|||
|
|
业务层包含所有业务逻辑。它由 services 类组成。它负责验证和授权。
|
|||
|
|
|
|||
|
|
3. 持久层
|
|||
|
|
|
|||
|
|
持久层包含所有数据库存储逻辑。它负责将业务对象转换为数据库行，反之亦然。
|
|||
|
|
|
|||
|
|
4. 数据库层
|
|||
|
|
|
|||
|
|
数据库层包含所有数据库，如 MySql、MongoDB 等。此层可以包含多个数据库。它负责执行 CRUD 操作。
|
|||
|
|
|
|||
|
|
|
|||
|
|
解释：
|
|||
|
|
|
|||
|
|
客户端发出 HTTP 请求（GET、PUT、POST 等）
|
|||
|
|
HTTP 请求被转发到 Controller。控制器映射请求。它处理句柄并调用服务器逻辑。
|
|||
|
|
业务逻辑在 Service 层执行。Spring Boot 对通过 Java Persistence Library （JPA） 映射到 spring boot 模型类的数据库数据执行所有 logic 。
|
|||
|
|
JSP 页作为控制器的 Response 返回。
|
|||
|
|
|
|||
|
|
### 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
|
|||
|
|
+- MyApplication.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
|
|||
|
|
+- MyApplication.java
|
|||
|
|
|
|
|||
|
|
+- domain
|
|||
|
|
| +- Customer.java
|
|||
|
|
| +- Order.java
|
|||
|
|
|
|
|||
|
|
+- controllers
|
|||
|
|
| +- OrderController.java
|
|||
|
|
| +- CustomerController.java
|
|||
|
|
|
|
|||
|
|
+- services
|
|||
|
|
| +- CustomerService.java
|
|||
|
|
| +- OrderService.java
|
|||
|
|
|
|
|||
|
|
+- repositories
|
|||
|
|
+- CustomerRepository.java
|
|||
|
|
+- OrderRepository.java
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
尽管上述结构看起来可行并且很容易按层定位类。与 Structure by Feature 相比，它几乎没有缺点。
|
|||
|
|
|
|||
|
|
功能部件或模块不能单独发布。
|
|||
|
|
很难找到与某个功能相关的类。
|
|||
|
|
对某个特征进行代码重构是困难的，因为特征类位于每一层中。
|
|||
|
|
它会导致使用 Git 等进行协作的开发人员之间发生合并冲突。
|