前端学习之后端小白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;                    // 来自 TestFeatureDO
    private 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() 方法
 @Override
 public 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(...);
    // 只测试格式转换
}

总结

这种分层设计虽然看起来复杂，但它带来的可维护性、可扩展性和可测试性是巨大的，特别是在大型企业级系统中，这种设计模式是必不可少的。