JavaEE三层架构实战：传统文化学习系统开发全解析

1. 这个项目到底在做什么

1.1 业务范围与目标用户

第一次拿到“基于JavaEE的传统文化学习系统（11818）”这个题目，我盯着后面的编号看了半天。做过毕业设计或者课程项目的人应该都知道，这种带括号编号的题目，通常来自某个项目库，题目本身没变过，但每年都有人选它，代码水平高低全看个人发挥。

先说清楚系统本身要干什么。传统文化学习，本质是把文化资源数字化之后，提供一个在线平台，让用户去浏览、分类、检索、学习，甚至做点小测验来自测。这就决定了它至少需要两块核心功能：一块是面向普通用户的“学”，一块是面向管理员的“管”。

学的那一侧，要解决的是怎么让用户方便地获取内容。传统文化资源种类非常多，诗词、成语、典故、节庆、曲艺、书法、国画、传统手工艺，甚至地方民俗都能算。你不可能全堆在一个页面上，必须按分类组织，配合搜索和热门推荐，让用户能按自己兴趣往下钻。

管的那一侧，则要解决内容运营的问题。管理员需要能新增文化条目、编辑内容、调整分类、控制上下架状态，以及查看用户的学习记录和测验成绩。只有把这两块做完整了，这个系统才不是传统意义上那种“花架子项目”，而是能真正跑起来、有业务闭环的东西。

这类题目的用户画像也很典型：要么是高校学生用来交课程作业，要么是初学JavaWeb的开发者拿来做入门练手。如果你属于这两类人，这篇博文就是照着你的实际需求写的。

1.2 为什么这类题目常年被选却不落伍

很多人会带着偏见看这类老牌题目：又是Servlet又是JSP，现在企业里都Spring Boot满天飞了，学这个是不是浪费时间？

我的看法比较现实：正因为它是老技术，教学和练习的完整成本才最低，踩坑路径也最清晰。你在做一个JavaEE经典结构项目时，要自己处理Web容器、JSP生命周期、过滤器链、数据库连接、事务管理、表单编码……这些东西在Spring Boot里大多被框架悄悄帮你包掉了，新手根本看不到底层在哪运作。而在传统的JavaEE三层架构里，每层都要你写出来、自己拼装起来——这恰恰是最宝贵的部分。

“传统文化学习系统”这个业务主题本身，也赋予了这个项目额外的练兵价值。它不是简单的增删改查，它涉及多表关联（用户和资源、分类和内容、学习和记录）、文件上传（展示位配图、文化图片）、状态流转（内容审核、上下架），这些业务逻辑越复杂，锻炼价值越高。后面文章会逐个模块拆开讲。

2. 技术栈的取舍逻辑

2.1 为什么是JavaEE，而不是直接上Spring家族

如果只看“能实现”这个标准，Spring Boot确实能做得更快。但请你先想想老师布置这类题目的意图是什么。JavaEE（这里特指传统的Servlet + JSP + JDBC方案）是让你理解Web应用最底层的运行机制：请求进来如何被容器处理、Servlet如何声明周期运转、Session如何跨请求保持状态、JSP如何在服务端渲染成HTML、JDBC如何跟数据库建立连接并管理事务。

Spring Boot最大的问题在于“过度的自动装配”。你写一个Controller，标注几个注解，方法就执行了，数据库操作也通过自动配置接上了。但容器到底怎么根据URL找到某个Servlet的？Session到底存在哪、什么时候失效？这些基础问题如果你没有亲手在web.xml里配置过Servlet映射、没有伸手写过HttpSession的操作，确实很难建立起系统认识。

不过我得把话说全：不是说Spring不好，而是这个题目面前，技术是为教学服务的，练习的价值远大于用新框架快速凑出来。真到了企业项目，Spring Boot是绝对主流，可你在面试时聊JavaWeb基础，聊HTTP会话、过滤器、监听器，这些从传统JavaEE项目里练出来的底子反而成了加分项。

2.2 一整套可落地的技术选型方案

直接给一套经过验证的组合，照着抄就不会乱：

这套组合的优点是依赖非常少，符合“单体课程项目”的体量，不引入MyBatis或Hibernate是为了把精力留在理解SQL和事务控制上。等你把JDBC那套手动映射表的代码写恶心了，自然能体会到MyBatis存在的意义——这种感悟，直接学框架是拿不到的。

2.3 三层架构，如何划分才算合理

传统JavaEE项目一定要分层，这是项目后续对不对得上评分标准的核心所在。我习惯分成四层：Control（Servlet控制层）、Service（业务层）、Dao（数据访问层）、Domain（实体模型层），再额外加一个util包放通用工具类。

各层之间规则要定死：

• Servlet层只做三件事：接收请求、取出参数、把数据交给Service层并调度页面跳转。绝不能在里面写SQL。
• Service层承载业务逻辑，比如说用户注册时的密码加密、用户名唯一性校验、学习进度计算、管理员新增文化条目时校验分类是否存在。事务边界最好也在这一层控制。
• Dao层只负责与数据库交互，写SQL、设置参数、处理ResultSet转对象。不参与任何业务流程判断。
• Domain层是纯粹的JavaBean，对应数据库表结构，只扛数据。

我在很多学生代码里看到的问题，就是Servlet里既写SQL又写逻辑，Service层形同虚设，最后Debug的时候哭都哭不出来。分层刚开始会多写几个类，但等你改到第三个功能的时候就会感激当初的克制。

3. 数据库设计：五张表撑起整个系统

3.1 表结构的业务推导逻辑

传统文化学习系统虽然功能看起来多，但数据库表数量其实用五张核心表就够覆盖主要业务。不要一上来就设计二十张表，复杂的东西大多是你硬造出来的。

我们要反着来，先想业务需要什么，再反推出表结构。用户登录了，得有一张user表存账号信息；用户要看文化内容，得有一张resource表存具体文化条目；资源不能是一锅粥，要有分类，所以有category表；用户对哪些内容感兴趣、学了哪些、收藏了哪些，有user_action表；用户做测验要记录成绩，所以有exam_record表。

这是最底层、最必要的五张表。至于管理员？我认为不需要单独建admin表，直接在user表里加一个role字段区分普通用户和管理员，简单直接，也够用。系统初期维护者也就一两个人，没必要做成RBAC模型那么复杂。

3.2 每张表的核心字段与设计要点

user表（用户表）

核心字段是id、username、password、nickname、avatar、role、status、create_time。password必须存加密后的密文，明文这种操作在项目里第一时间就否定掉。role字段用tinyint存，0表示用户，1表示管理员。status表示账号是否被锁定，这是给后台禁用用户做准备的。

category表（分类表）

核心字段是id、name、description、sort_order、parent_id。parent_id很重要，让分类可以做成两级结构。举个例子，一级分类“传统文学”下面挂二级分类“唐诗”“宋词”“散文”，用户进入一级分类后能继续下钻，体验比平铺一列好得多。

resource表（文化资源表）

这是整个系统的核心表，字段必须考虑周全：id、category_id、title、summary、content、cover_image、source、author、is_ hot、status、create_time、update_time。

content字段用MEDIUMTEXT类型，因为传统文化条目可能很长，比如一篇几千字的典故考据，TEXT容易不够用。author字段记录原作者，像“记录人：某单位文化研究员”这种。source字段标记内容来源，保证日后追溯。is_hot用来标记热门内容，方便首页推荐位拉取。status是关键状态字段，0草稿、1已发布、2已下架，让管理员对内容生命周期有控制权。

user_action表（用户行为表）

核心字段是id、user_id、resource_id、action_type、create_time。action_type用整型记录行为类型：1收藏、2浏览、3点赞。这张表是用来支撑“我的收藏”“浏览历史”“热点内容排行”这些个性化功能的。注意给user_id和resource_id建联合索引，否则数据量上去后查询会明显变慢。

exam_record表（测验记录表）

核心字段是id、user_id、category_id、score、total_score、create_time。测验模式就两种：按分类抽题，或者随机抽题。每次测验完成后写一条记录。score和total_score分开存，是为了后面做正确率统计。

3.3 建表脚本里容易被忽略的东西

建表时有三件事，我建议你一开始就做对：

第一，统一字符集。所有表统一用utf8mb4，不要问为什么不用utf8。传统文化内容里有大量生僻字，比如“龘”“爨”，utf8（3字节）存不下部分扩展区字符，而utf8mb4可以。当初我在某个演示现场看到所有生僻字全部变成问号，那场面实在尴尬。

第二，外键策略要想清楚。课程设计阶段，外键约束看着严谨，但真到了自己插入测试数据时，频繁被外键卡住非常烦躁。我的建议是：表与表之间的关联字段照常命名，比如resource表里的category_id，但从物理上不要真建外键约束，逻辑关联就够了。这么做不是因为懒，而是为了方便测试数据的写入和清理。你要在文档里说明白，这是“逻辑外键优先”的取舍。

第三，初始化数据必须有。建完表之后，至少准备10条以上的分类数据，每类下面再配20到30条完整内容。没有初始数据，页面永远是空荡荡的，演示效果直接减半。很多人代码写得挺好，一打开网站啥内容都没有，评分的印象分当场就低了一截。

下面是精简版建表脚本，可直接作为基础跑通：

CREATE DATABASE culture_learning DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE culture_learning; CREATE TABLE user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), role TINYINT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE category ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, description VARCHAR(255), parent_id INT DEFAULT 0, sort_order INT DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE resource ( id INT AUTO_INCREMENT PRIMARY KEY, category_id INT, title VARCHAR(200) NOT NULL, summary VARCHAR(500), content MEDIUMTEXT, cover_image VARCHAR(255), source VARCHAR(100), author VARCHAR(100), is_hot TINYINT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_category (category_id), INDEX idx_hot (is_hot) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE user_action ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT, resource_id INT, action_type TINYINT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_action (user_id, action_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE exam_record ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT, category_id INT, score INT DEFAULT 0, total_score INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这套表设计能达到什么效果？用户来网站，先按分类浏览，再点进具体条目阅读全文，看完觉得好的一键收藏；管理员进后台，能发新内容、编辑旧内容、管理分类、查看每个用户的测验成绩。前端展示全部落实，后端管理完全兜底，整个业务闭环就成型了。

4. 核心功能模块与实现过程

4.1 用户认证：从登录注册到Filter拦截

用户模块是整个系统的入口。没有登录，收藏不了、测验做不了、个人学习记录也保存不了。所以认证逻辑必须一开始就搭好架子。

我建议把注册、登录、登出放在一个UserServlet里，用action参数区分操作类型。前端JSP里提交表单的时候，地址写成user?action=register或者user?action=login。Servlet里先处理中文参数编码，再调到Service层做校验。

注册的时候要做三件事。第一，用户名重复检查，这个必须走DB查询，不能只看前端校验，因为前端是可以绕过的。第二，密码加密存储，推荐用MD5加盐或者SHA-256，不用去追时髦用BCrypt，课程项目里SHA-256加固定盐足够演示。第三，默认角色是普通用户，默认状态是启用。

登录成功之后，把用户信息放进Session：

HttpSession session = request.getSession(); session.setAttribute("loginUser", user); session.setAttribute("isLogin", true);

接下来就是Filter拦截登录状态。传统做法是在web.xml里配置一个LoginFilter，url-pattern设定为需要登录才能访问的路径前缀。由于系统里有用户主页、收藏、测验等受保护资源，拦截范围要把这些请求都包住：

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); boolean isLogin = (session != null && session.getAttribute("loginUser") != null); if (isLogin) { chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } }

登录拦截器的逻辑不复杂，但有个细节容易忽略：请求的是JSP页面还是Servlet路径。如果拦截的是JSP，用户直接输地址访问某个受保护的JSP，也可以被拦住；但是你的JSP里可能嵌套了静态资源（CSS、JS、图片），这些也要配置放行，否则页面样式会加载不出来。老老实实写一个对应的放行规则，把/assets、/css、/js这类路径排除掉。

4.2 传统文化内容的展示与检索

资源列表是用户看到的第一个页面形态。设计上有一个关键选择：首页展示什么、分类页展示什么、搜索页展示什么，三种场景可以共用一个ResourceServlet，通过参数来切换。

参数设计大体是：action=list（列表）、action=detail（详情）、action=search（搜索）、action=hot（热门推荐）。

列表页要做成分页模式，不要一次性把所有数据查出来。自己写一个Page类，装pageNum、pageSize、totalCount、totalPage、dataList这五个字段，配合LIMIT offset, size实现分页查询。分页SQL写起来非常简单：

SELECT * FROM resource WHERE status=1 AND category_id=? ORDER BY create_time DESC LIMIT ?, ?;

offset = (pageNum - 1) * pageSize，pageSize定为10，体验适中。

详情页是内容消费的核心页面。用户点进一篇典故或者一条节气介绍，页面要把标题、分类、摘要、正文、来源、作者全部渲染出来，同时根据resourceId把阅读数或者热度标记更新一下。我的做法是在Service层做双重更新：查看详情时，向resource表的view_count字段加1；同时向user_action表插一条浏览记录——前提是用户已登录。

搜索功能要用模糊查询。MySQL的LIKE '%keyword%'就能胜任，数据库数据量在几万条以内性能完全够用。同时搜索范围最好扩展几个字段，title、summary、author都查一遍，让结果更全。我实测过，很多用户搜的是半截关键词，比如输“四时”想找“四时八节”，这种多字段模糊匹配的命中率明显高。

首页热门推荐的核心逻辑就一个：把is_hot = 1且status = 1的资源查出来，按时间倒序取前6条展示。这块缓存不缓存暂不考虑，课程项目阶段直接查库就行，又不是成百上千的QPS。

4.3 学习测验的简单可用的设计

测验功能是这个系统的加分项，也是很多人的选题难点。传统做法有两种：一是按分类抽取固定数量的题目；二是全网随机抽题。我建议优先做按分类抽题，因为实现简单，且业务逻辑清晰。

数据库里需要加一张exam_question表，存题目和答案选项。字段包括id、category_id、question、option_a、option_b、option_c、option_d、correct_option、analysis。表里每道题附带答案解析，测验交卷后能够即时反馈，学习体验比干巴巴的ABCD高一个级别。

抽题逻辑：

SELECT * FROM exam_question WHERE category_id = ? ORDER BY RAND() LIMIT 10;

ORDER BY RAND() 在数据量少时没问题，如果题目表超过几千条，性能会差一些，但课程项目完全在可用范围内。交卷时在前端用JavaScript把用户选中的答案收集起来，提交到ExamServlet，Service层对比正确答案逐题判分，最后插入exam_record表。

4.4 后台管理功能的设计思路

传统JavaEE项目的后台不建议做得太重，但一定要有。后台入口是一段独立路径，比如admin/开头。登录时判断role字段是否为1，不是管理员一律不给进。

后台管理列表包含用户管理、分类管理、资源管理、测验记录四个页签。资源管理是核心，需要支持增删改查和上下架。新增资源时的表单字段很多：标题、分类下拉框、摘要、正文、封面图片、来源、作者、是否热门。这里比较麻烦的是图片上传，表单要设置enctype="multipart/form-data"，然后用Servlet 3.0自带的Part接口接收文件，保存到服务器的upload目录，并把相对路径写到数据库。

很多人第一次写文件上传都会踩这个坑：表单忘了加enctype属性，后台一直拿到的是普通字符串而不是文件内容。这是最典型的低级错误，希望你不是看完了这篇文章再去踩一遍。

后台管理页面的权限控制可以直接复用Filter，新增一个AdminFilter，只在admin/*路径下生效，判断思路跟LoginFilter一致，但还要追加一个role == 1的判断条件。

5. 实际调试中踩过的坑与解法

5.1 中文乱码，十个项目九个中的招

做JavaEE项目，中文乱码真的是最高频的问题，没有之一。乱码的出现位置大概有三个：请求参数乱码、响应页面乱码、数据库读写乱码。

先记住一个排查原则：全链路统一UTF-8。浏览器发送请求，Tomcat解析请求，Servlet读取参数，JDBC写入MySQL，MySQL返回数据，再被JSP渲染出来，这一整条链路上任何一环的编码不统一，就会出现肉眼可见的乱码。

解决方案如下：

在web.xml里配置CharacterEncodingFilter，这是全部方案里最稳定的一招：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>com.culture.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

对应的过滤器实现里面，只做一件事：请求和响应都设置成UTF-8。

request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8");

数据库连接URL也要显式声明编码：

jdbc:mysql://localhost:3306/culture_learning?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai

JSP页面顶部声明：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

三处配置都做对了，乱码问题可以直接消失。如果还乱，就检查MySQL表本身的字符集，用SHOW CREATE TABLE语句看看是否仍然落在latin1或者utf8上面。

5.2 JSP里写大量Java代码引发的连锁问题

很多人图省事，在JSP里直接写<% ... %>代码块做循环遍历，一开始看着挺快，但越补越歪。我见过一个项目，整个界面逻辑与服务端逻辑完全揉在一起，改一个查询条件要找遍三个页面。

更好的方案是引入JSTL标签库。EL表达式配合JSTL的<c:forEach>、<c:if>，把循环和条件判断从Java代码块里解放出来。JSTL的核心价值不只是代码整洁，它天然避开了Scriptlet作用域混乱的大坑。

使用前在Maven里引入依赖：

<dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency>

JSP里声明标签库，然后这样展示列表：

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> <table> <c:forEach items="${resourcePage.dataList}" var="res"> <tr> <td>${res.title}</td> <td>${res.categoryName}</td> <td><a href="resource?action=detail&id=${res.id}">查看</a></td> </tr> </c:forEach> </table>

注意${res.categoryName}这个字段，Resource实体里本身可能没有categoryName属性，是查询时通过JOIN把分类名字查出来再set进对象里的。这种关联查字段的习惯，会让页面展示省掉很多二次查询。

5.3 热门内容统计和列表页性能

传统文化系统的数据量级再大也就几千条，性能问题理论上不会太严重。但架不住有些人把列表页做成全表查询，再叠加一个嵌套循环去查每个资源的分类名称，结果就是N+1次查询，数据量一上去页面秒开变一秒以上。

解决办法有两个方向。第一个方向是JOIN一次查完，SQL写清楚连表字段，不要在Service层循环查询：

SELECT r.*, c.name AS category_name FROM resource r LEFT JOIN category c ON r.category_id = c.id WHERE r.status = 1 ORDER BY r.create_time DESC LIMIT ?, ?;

第二个方向是“热门推荐”这种高频且结果稳定的查询，可以做内存缓存。用一个静态Map，key是缓存标识，value是查询结果列表，第一次查询后把结果放进去，设定每分钟刷新一次。这个做法能体现出你比普通课程项目多懂了一点点性能意识，加分效果很明显。

5.4 文件上传与虚拟目录映射

上传图片保存到服务器本地之后，另一个隐藏问题马上出现：Tomcat默认不会把upload目录直接映射成可访问的URL路径。也就是说你辛辛苦苦把图片保存到硬盘上了，但根本显示不出来。

解决方式是在Tomcat的conf/server.xml里配置虚拟目录，或者在代码里用资源映射处理。更省事的做法是：把图片存到项目的WebContent/upload目录下，这样发布后它就属于Web应用根路径，直接通过相对路径就能访问。它的缺点是重新部署工程时图片会丢，但对于课程项目，演示优先，应用场景完全够用。

如果非要保存到外部路径，就老老实实在server.xml的Host节点下加一行docBase配置，这是更具工程感的做法：

<Context path="/upload" docBase="/data/culture/upload" reloadable="true"/>

6. 从项目构建中学到的东西

这个项目做完之后，给我最深刻的体会不是技术含量，而是技术复杂度与业务完整度如何平衡。

一个传统文化学习系统，如果只看技术，本质上就是Servlet + JSP + MySQL，没有任何惊艳的算法或模式。但你要把传统诗词、节庆民俗、曲艺艺术这些内容安排得井井有条，让用户有分类浏览、有搜索、有收藏、有测验，复杂度就上来了。也就是在“业务深度”上打磨，才是这类题真正锻炼人的地方。

第二个体会，老技术不代表可以乱写。分层架构、事务边界、编码规范这些基本功，恰恰在传统JavaEE项目里最容易被检验。你写完Service层，再回头看那几百行代码，如果Service层还能保持清爽、没有堆砌SQL，说明你已经有了良好的工程意识，这种意识带到任何新技术框架中都受益。

第三点也是我最想说的一点：不要迷信框架，也不要贬低基础。我见过不少同学，简历上写着“精通Spring Boot”，但是连Session和Cookie的区别都讲不清。Spring是工具箱，JavaEE基础是手。工具可以换，手不能没。传统文化学习系统这个题目给了一个很好的训练环境，它逼着你从HTTP协议、Servlet生命周期、会话管理、JDBC这些最原始的环节开始，把一条请求从浏览器到数据库再回到浏览器的完整路径彻底走通。走通了这条路，后面学什么框架都只是锦上添花。

最后分享一个小建议：做这个项目的时候，尽量把传统文化内容本身也做扎实。哪怕只是虚拟的示例数据，也尽量真实、分类准确，别用一堆“测试内容1”“测试内容2”顶着。一个内容丰富的系统，在演示的时候自带说服力。技术是骨架，内容才是血肉，两者都到位，这个项目才算真正立住了。