当前位置：首页 > news >正文

从混乱到秩序：Java Web 分层学习的迭代之路

news 2026/5/31 0:24:06

一、总：为什么分层不能一蹴而就？

很多初学者学 Java Web 时，一上来就被灌输了“标准三层架构”：Controller、Service、DAO、Entity……然后照着模板写代码，却始终不理解为什么要多写这么多类和接口。结果往往是：分层流于形式，代码越改越乱，甚至比不分层还难维护。

真正的分层不是设计出来的，而是生长出来的。本文提出一种“迭代法学习路径”：
先写一个什么都干的“上帝 Controller” → 随着业务复杂，自然抽离 Service 层 → 再进一步抽离持久层 → 最后引入 Spring Boot 解决工程化困境。
整个过程遵循奥卡姆剃刀原则——如非必要，勿增实体。让学习者在每一次“痛”中理解分层的价值，最终真正掌握分层架构的灵魂。

二、分：四步迭代，从混沌走向秩序

第一阶段：上帝 Controller —— 允许一切从简单开始

目标：快速搭建一个可运行的 Web 应用，所有业务逻辑、数据访问、页面跳转全部写在一个 Controller 里。

示例场景：一个简单的图书管理功能，只有“查看所有图书”和“添加新书”。

@WebServlet("/book")
public class GodController extends HttpServlet {// 假设内存里有个 List<Book> 模拟数据库private List<Book> books = new ArrayList<>();protected void doGet(HttpServletRequest req, HttpServletResponse resp) {String op = req.getParameter("op");if("list".equals(op)) {req.setAttribute("books", books);req.getRequestDispatcher("/bookList.jsp").forward(req, resp);}}protected void doPost(HttpServletRequest req, HttpServletResponse resp) {String name = req.getParameter("name");books.add(new Book(name));resp.sendRedirect("book?op=list");}
}

这个阶段学到什么？

· 理解 HTTP 请求流转、页面跳转、参数获取。
· 感受到原始的快乐：代码集中，改一处逻辑不用翻来翻去。
· 也为未来的“痛”埋下伏笔：当业务膨胀时，这个类会变得臃肿难读，测试困难，逻辑复用为零。

关键原则：在不需要复杂分层时强行分层，只会增加无意义的模板代码。先跑起来，再谈架构。

第二阶段：业务扩张 → Service 层自然涌现

触发条件：系统开始增加“用户”、“管理员”等身份，出现多处共享的业务规则。例如：

· 添加图书时，需要验证书名不能为空、不能重复。
· 删除图书时，需要检查当前用户是否有权限。
· 这些验证规则既在 Web 端用到，也可能在定时任务、REST 接口中用到。

此时感受到的痛：同一个验证逻辑写在多个地方，改一处要改 N 处；GodController 已经超过 500 行，没人愿意维护。

解决方案：把业务规则抽离成 Service 层。Controller 只负责接收请求、调用 Service、返回视图。

// 业务层
public class BookService {public void addBook(String bookName) {// 复杂的验证逻辑、业务计算都在这里if(StringUtils.isBlank(bookName)) throw new IllegalArgumentException();// 调用持久层（暂时还没有，先模拟）}
}// Controller 瘦身
@WebServlet("/book")
public class BookController {private BookService bookService = new BookService();protected void doPost(...) {bookService.addBook(req.getParameter("name"));resp.sendRedirect(...);}
}

这个阶段学到什么？

· Service 层隔离了业务逻辑和 Web 协议：可以在不修改 Controller 的情况下，单独测试 Service。
· 当需要给移动端提供 API 时，只要再写一个 RestBookController，复用同一个 BookService 即可。
· 真正理解：分层不是“多写一个类”，而是职责分离。

关键原则：非必要不增加实体。只有当 Controller 里的逻辑已经无法清晰维护、无法复用时，才抽出 Service。这个“痛”就是最好的老师。

第三阶段：数据多样化 → 持久层自然抽离

触发条件：系统需要从内存数据库换成 MySQL，或者需要支持多种数据库（如测试用 H2，生产用 MySQL）。此外，每个 Service 方法里都重复写着 JDBC 代码：Connection、PreparedStatement、ResultSet、异常处理……

此时感受到的痛：

· 换数据库要改几十个 Service，改到崩溃。
· 同样的 SQL 拼接散落在各处，极易出错。
· 数据访问的细节污染了业务逻辑，一改数据库表结构，Service 也得跟着改。

解决方案：抽离 DAO（Data Access Object）+ Entity 层。

· Entity：与数据库表一一对应的 Java 对象，是数据的运行时载体。
· DAO：封装所有 CRUD 操作，让 Service 完全不感知底层是 MySQL 还是文件。

// Entity
public class Book {private Long id;private String name;// getter/setter
}// DAO 接口
public interface BookDao {List<Book> findAll();void save(Book book);
}// DAO 实现（JDBC 模板）
public class BookDaoJdbcImpl implements BookDao {public List<Book> findAll() {// 具体的 JDBC 代码}
}// Service 只依赖接口
public class BookService {private BookDao bookDao; // 通过构造注入public void addBook(String name) {Book book = new Book();book.setName(name);bookDao.save(book);}
}

这个阶段学到什么？

· 持久层隔离了数据存储的细节：要换数据库，只需换一个 DAO 实现，Service 一行不改。
· Entity 让数据结构清晰：再也不需要用 Map<String, Object> 到处传数据。
· 之前所谓的“三层架构”现在才真正完整，而且每一层都是在无法忍受混乱时自然涌现出来的，不是凭空拍脑门。

关键原则：勿增实体并不意味着永远不加类，而是在真正需要的时候才加。持久层是最后出现的，也是最稳定的一层。

第四阶段：工程化困境 → Spring Boot 全面接管

触发条件：项目已经成长为一个小型产品：有十几个 Service、二十几个 DAO、多个拦截器（权限、日志）、需要事务管理、需要连接池、需要整合第三方服务（如 Redis、消息队列）。此时开发人员每天都在写重复的配置代码：

· 每个 Service 都要手动 new 依赖，想要换一个 DAO 实现得改好几个文件。
· 每个方法都要手动开启/提交/回滚事务，漏掉一个就出 bug。
· 写一个拦截器要配 web.xml，加一个过滤器又要配一遍。
· 打包部署要配置 web.xml、配置数据源、部署到 Tomcat 并手动启动……
· 用 Maven/Gradle 管理了 JAR 包版本，但各 JAR 包之间的兼容性问题、传递依赖冲突让人焦头烂额。

此时感受到的痛：

· 重复的样板配置已经远超真正的业务代码。
· 项目启动慢、测试困难、多人协作时每人电脑环境不一致。
· 开始怀念第一阶段“上帝 Controller”的简单——但也知道，那种简单无法支撑现在的规模。

解决方案：引入 Spring Boot。它不是要推翻之前的分层成果，而是接管基础设施，让开发者专注于业务。

Spring Boot 解决了哪些“痛”？

原生开发的痛点 Spring Boot 的解法
手动管理对象依赖（new、构造器传参） IoC 容器：用 @Autowired 自动注入，只需定义接口，容器帮你组装
到处写 try-catch-finally 管理事务声明式事务：@Transactional 一行搞定，出现异常自动回滚
配置 web.xml、数据源、拦截器很繁琐自动配置：引入 spring-boot-starter-web 就自动配好 Tomcat、DispatcherServlet
整合第三方库（Redis、MQ）需要大量配置 Starter 依赖：spring-boot-starter-data-redis 开箱即用，极少配置
打包部署麻烦，每台机器要装 Tomcat 内嵌 Servlet 容器：java -jar 直接运行，环境一致性有保障
依赖版本冲突、传递依赖混乱 Spring Boot Parent + Starter：精选的版本组合，减少 95% 的版本冲突
单元测试要启动整个 Web 容器 @SpringBootTest + 内嵌 Mock 环境，测试快如闪电

迭代改造示例：从原生到 Spring Boot

改造前（原生三层）需要手动组装依赖：

// 手动创建依赖链
BookDao dao = new BookDaoJdbcImpl();
BookService service = new BookService(dao);
BookController controller = new BookController(service);

改造后（Spring Boot）只需声明依赖关系：

@Service
public class BookService {@Autowiredprivate BookDao bookDao;  // 容器自动注入具体的 DAO 实现
}@RestController
public class BookController {@Autowiredprivate BookService bookService;@PostMapping("/book")public Result addBook(@RequestParam String name) {bookService.addBook(name);return Result.success();}
}

至于 BookDao 的具体实现是 Jdbc 还是 MyBatis，通过配置文件 application.properties 一行就能切换，Service 代码零修改。

这个阶段学到什么？

· 框架不是来取代分层的，而是让开发者更专注于业务分层。Service、DAO、Entity 概念在 Spring Boot 中依然完全适用，只是不用再写那些啰嗦的创建和管理代码。
· 自动配置不是魔法：依然需要理解底层的 Tomcat、JDBC、事务原理，但 Spring Boot 帮助避免了重复劳动。
· “约定优于配置” 是奥卡姆剃刀在框架层面的体现——在大多数情况下，框架的默认约定已经够用，不必为每个细节写配置。

关键原则：非必要不增加配置。Spring Boot 的理念与“如非必要，勿增实体”高度一致——只有当默认约定不满足时，才写额外配置。不会再看到一个几百行的 web.xml 或 spring.xml。