前端學習之后端小白java的一些理論知識（框架）

一、Spring Framework 和 Spring boot的區別

核心定位

Spring Framework：一個全面的Java應用開發框架，提供核心功能如IoC容器、AOP等
Spring Boot：Spring Framework的擴展，專注于簡化Spring應用的初始搭建和開發過程

配置方式

Spring Framework：需要大量XML配置或Java注解配置
Spring Boot：采用"約定優于配置"，自動配置大部分組件，極少配置即可運行

應用部署

Spring Framework：通常需要外部應用服務器（如Tomcat、Jetty）
Spring Boot：內嵌應用服務器，可直接生成獨立可執行的JAR文件

開發速度

Spring Framework：搭建項目需要手動配置各種依賴和設置
Spring Boot：使用starter依賴和自動配置，快速啟動項目

依賴管理

Spring Framework：需要手動管理依賴版本兼容性
Spring Boot：提供依賴管理，自動處理依賴版本兼容問題

監控和管理

Spring Framework：需要額外配置監控工具
Spring Boot：內置Actuator提供監控和管理功能

使用場景

Spring Framework：適合需要精細控制每個組件的大型復雜項目
Spring Boot：適合快速開發、微服務架構和云原生應用

適用場景

Spring Boot更適合：
快速開發和原型設計
微服務架構
云原生應用
初學者和中小型項目
需要快速部署的場景
Spring Framework更適合：
需要精細控制框架配置的大型項目
對系統資源要求嚴格的場景
需要與遺留系統深度集成的項目
特殊的定制化需求

本質上，Spring Boot是在Spring Framework基礎上的一層封裝，簡化了開發流程，讓開發者可以更專注于業務邏輯而非框架配置。

總體而言，Spring Boot是Spring Framework的進化版，簡化了開發流程，但兩者并非替代關系。Spring Boot構建在Spring Framework之上，根據項目需求和團隊經驗選擇合適的方案更為重要。

二、java 有哪些框架

Web開發框架
Spring Framework：最流行的企業級開發框架
Spring Boot：簡化Spring開發的快速啟動框架
Spring MVC：基于MVC的Web框架
Struts2：老牌MVC框架
JSF：JavaServer Faces，組件化UI框架
Play Framework：輕量級、響應式Web框架
Micronaut：云原生微服務框架
Quarkus：為GraalVM和HotSpot優化的框架
ORM框架
Hibernate：最流行的JPA實現
MyBatis：輕量級SQL映射框架
JPA：Java持久化API標準
EclipseLink：JPA參考實現
jOOQ：類型安全的SQL構建框架
微服務框架
Spring Cloud：微服務生態系統
Dubbo：阿里巴巴RPC框架
gRPC：Google的高性能RPC框架
Helidon：Oracle的微服務框架
Vert.x：響應式微服務工具包
安全框架
Spring Security：認證和授權框架
Apache Shiro：輕量級安全框架
Keycloak：身份和訪問管理解決方案
JAAS：Java認證和授權服務
測試框架
JUnit：單元測試框架
TestNG：測試框架，JUnit替代品
Mockito：模擬測試框架
PowerMock：擴展其他模擬框架
Selenium：Web應用自動化測試
日志框架
Log4j/Log4j2：Apache日志框架
Logback：Log4j的后繼者
SLF4J：簡單日志門面
Commons Logging：Apache通用日志接口
工具框架
Apache Commons：通用工具庫
Guava：Google核心庫
Lombok：減少樣板代碼
Jackson/Gson：JSON處理庫
Netty：異步網絡應用框架
大數據框架
Hadoop：分布式存儲和處理
Spark：大規模數據處理引擎
Flink：流處理和批處理框架
Storm：實時計算系統

企業開發中，Spring生態系統（Spring Framework、Spring Boot、Spring Cloud）是最主流的選擇，結合MyBatis/Hibernate等ORM框架構成大多數Java企業應用的技術棧。

三、推薦開發順序：自底向上

數據庫表結構 (如果需要新增字段)
↓
Mapper 層
↓
Manager 層
↓
Service 層
↓
Controller 層
↓
響應對象

Controller層：處理HTTP請求
Service層：業務邏輯處理
Mapper層：數據訪問層（MyBatis）
Configs：配置類
通俗案例
```
1. **數據庫層**：需要修改 TestFeatureDO 和相關的 Mapper
2. **中間對象層**：需要修改 TestFeatureExtendInfo
3. **響應對象層**：需要修改 TestFeatureGetResponse
4. **數據庫查詢**：需要修改 TestFeatureServiceImpl 中的查詢邏輯
5. **響應轉換**：需要修改 convertExtentInfoToResponse 方法
```
優點：
? 確保數據可獲取性
? 每層都有扎實的基礎
? 便于單元測試
? 減少返工風險
這種自底向上的方式特別適合數據驅動的功能開發，能夠確保整個鏈路的數據流轉是可靠的。

四、每個層的具體職責

數據庫層(直接映射數據庫表)

  // TestFeatureDO.java - 數據對象public class TestFeatureDO extends BasicFeatureTypeDO {private String modelId;           // 對應數據庫 model_id 字段private String modelVersionId;    // 對應數據庫 model_version_id 字段  private String englishName;       // 對應數據庫 english_name 字段// ... 其他數據庫字段}

職責：
🎯 一對一映射：每個屬性直接對應數據庫表的一個字段
🎯 數據持久化：負責數據的增刪改查操作
🎯 類型轉換：處理數據庫類型到 Java 類型的轉換

中間對象層(業務處理中的擴展信息對象/業務邏輯處理和數據組裝)

 // TestFeatureExtendInfo.java - 業務擴展對象
public class TestFeatureExtendInfo extends FeatureExtendInfo {private String modelId;                    // 來自 TestFeatureDOprivate Map<String, Object> modelArgToFeatureNameMap; // 業務處理后的復雜對象private List<FeatureSubjectDO> subjectList;    // 關聯查詢的其他數據private List<FeatureBusinessDO> businessList;  // 關聯查詢的其他數據// ... 更多業務相關字段
}

職責：
🎯 數據聚合：將多個 DO 對象的數據組合在一起
🎯 業務邏輯：處理復雜的業務規則和計算
🎯 關聯查詢：整合來自不同表的相關數據

響應對象層(返回給前端的響應對象)

// TestFeatureGetResponse.java - 響應對象
public class TestFeatureGetResponse extends FeatureGetResponse {private String modelId;                    // 前端需要的字段private Long createTime;                   // 轉換為時間戳格式private BasicUserInfo creator;             // 封裝用戶信息對象// 只包含前端需要的字段，隱藏內部實現細節
}

職責：
🎯 API 契約：定義前端能獲取到的數據結構
🎯 格式轉換：將內部數據格式轉換為前端友好的格式
🎯 數據過濾：只暴露前端需要的字段，隱藏敏感信息

數據庫查詢(在Service層進行數據獲取/數據獲取和初步組裝)

 // ModelFeatureServiceImpl.get() 方法@Overridepublic TestFeatureGetResponse get(Long featureId, Long versionId, ...) {// 🔍 查詢基礎特征信息FeatureDO featureDO = featureManager.getById(featureId);// 🔍 查詢模型特征版本信息TestFeatureDO modelFeatureDO = TestFeatureManager.getById(versionId);// ... 組裝業務對象}

職責：
🎯 數據獲取：從多個數據源獲取原始數據
🎯 關聯查詢：處理表之間的關系查詢
🎯 數據驗證：確保數據的完整性和有效性

響應轉換(將中間對象轉換為響應對象/業務對象到響應對象的轉換)

// convertExtentInfoToResponse() 方法
public TestFeatureGetResponse convertExtentInfoToResponse(TestFeatureExtendInfo extendInfo) {TestFeatureGetResponse response = new ModelFeatureGetResponse();// 🔍 字段映射response.setModelId(extendInfo.getModelId());response.setVersionId(extendInfo.getFeatureTypeId());// 🔍 格式轉換response.setCreateTime(extendInfo.getCreateTime().getTime()); // Date → Long// 🔍 對象轉換response.setCreator(new BasicUserInfo(extendInfo.getCreatorMis(), extendInfo.getCreatorName()));return response;
}

職責：
🎯 數據映射：將業務對象的字段映射到響應對象
🎯 格式轉換：處理數據類型和格式的轉換
🎯 對象構建：創建前端需要的嵌套對象結構

為什么需要這么多層？

單一職責原則（SRP）
數據庫層 ← 只關心數據存儲
中間層 ← 只關心業務邏輯
響應層 ← 只關心接口契約

解耦和可維護性

// 如果沒有分層，所有邏輯混在一起：
public class BadExample {public String getFeature() {// 數據庫查詢 + 業務邏輯 + 格式轉換 混在一起// 難以維護、測試和修改}
}// 分層后，職責清晰：
public class GoodExample {// 查詢層：專注數據獲取// 業務層：專注業務邏輯// 轉換層：專注格式轉換
}

變更隔離
數據庫表結構變更 → 只影響 DO 層
業務邏輯變更 → 只影響 ExtendInfo 層
前端接口變更 → 只影響 Response 層

復用性

// 同一個業務對象可以轉換為不同的響應格式TestFeatureExtendInfo extendInfo = ...;// 詳細響應TestFeatureGetResponse detailResponse = convertToDetailResponse(extendInfo);// 列表響應  TestFeatureListResponse listResponse = convertToListResponse(extendInfo);

測試友好

// 可以獨立測試每一層
@Test
public void testDataLayer() {ModelFeatureDO result = mapper.getById(1L);// 只測試數據訪問
}@Test  
public void testBusinessLayer() {ModelFeatureExtendInfo result = service.buildExtendInfo(...);// 只測試業務邏輯
}@Test
public void testResponseLayer() {ModelFeatureGetResponse response = converter.convert(...);// 只測試格式轉換
}