HIT-JavaEE | 从一张 UML 图开始，我把 JDBC、Servlet 和 JSP 一点点接了起来

有些课程作业，交完就应该结束了；但 JavaEE 这组实验，我后来总觉得还欠它一篇像样的记录。不是因为它有多么先进，恰恰相反，它里面有不少今天看来已经过时的写法。可我第一次真正把“一个请求是怎样穿过程序、碰到数据库、再回到浏览器”的过程串起来，就是在这门课里。

那时候我对 Java Web 的理解很像站在一栋楼外面看窗户：知道有 Servlet、JSP、JDBC，也能把代码写出来，但它们为什么要这样分工，出了问题应该从哪一层查，心里其实没有底。于是这几个实验就像一条不太平整的路，把我从 UML 图一路带到了学生管理页面。

仓库地址：KALEsky/HIT-JavaEE-Labs。里面保留了四个个人实验和一个分组大作业，代码、任务书和说明都按实验阶段重新整理过。

实验一：先别急着写代码，试着把系统画出来

第一个实验交给我的是一张 UML 图，入口文件是 Work1.uml。现在回头看，它不像后面几个实验那么“能跑”，甚至很容易让人觉得只是画图作业。但当时我第一次认真遇到一个问题：一个系统里的对象，到底应该怎样分工？哪些东西只是数据，哪些东西承担行为？对象之间的关系是暂时的调用，还是长期存在的组合？

刚开始我更在意图画得像不像，后来才发现，真正难的是把脑子里的模糊想法落成一组明确的关系。一旦类之间的边界没有想清楚，后面写代码时就会不停补洞：这个方法到底放在哪里，这个对象该不该知道数据库，页面是不是不应该直接改数据。

这次实验没有给我什么惊天动地的结果，却给后面几次实验埋下了一个很重要的习惯：先问清楚“谁负责什么”，再开始敲代码。它听起来像一句很普通的话，但在第一次课程项目里，真的很容易被忽略。

实验二：回调、控制台和文件复制，代码开始有了自己的脾气

第二个实验从图转到了程序。里面有控制台交互、回调思路，也有文件复制等操作。它最有意思的地方，是让我开始意识到“实现一个功能”和“让调用者能够使用这个功能”不是一回事。

比如文件复制看起来非常直接：打开输入文件，读一段，再写出去。可一旦把读取、遍历、复制和输出混在一起，代码很快就会变得难以修改。后来我尝试把“做什么”和“怎么遍历/复制”拆开，虽然最终的代码仍然带着课程作业的痕迹，但这种拆分让我第一次感受到接口和回调并不是为了显得高级，而是为了给变化留一点位置。

那段时间我经常有一种很具体的挫败感：代码明明只有几十行，真正读起来却比想象中费劲。后来我发现，问题不一定在语法，而在于自己没有把数据流画出来。输入从哪里来，中间经过谁，最终写到哪里——一旦把这条线捋顺，很多“看起来玄学”的问题就会变得普通。

实验三：第一次和数据库正面交手，JDBC 连接成功的那一刻很短

第三个实验终于把程序接到了数据库。代码里出现了 JDBC 连接、实体对象和 DAO，项目也从单纯的控制台程序变成了一个有数据读写的应用。

我当时最容易误判：看到控制台没有报错，以为已经成功；但真正要确认的事情其实更多——连接是不是拿到了，SQL 有没有执行，结果集有没有被正确转换成对象，连接和语句有没有关闭，异常到底发生在数据库、驱动还是自己的代码里。

仓库里的数据库配置已经改成环境变量示例，核心配置包括：

JAVAEE_DB_URL=jdbc:mysql://127.0.0.1:3306/hit
JAVAEE_DB_USER=root
JAVAEE_DB_PASSWORD=change-me

这不是为了把项目包装得更现代，而是因为把用户名和密码直接写进源码，既不安全，也会让代码离开自己的电脑就无法使用。课程实验里常见的硬编码，在当时可能只是为了赶紧跑起来；但现在重新整理时，我终于能看见它的代价。

实验里还有字符串拼接 SQL。它能完成查询，却留下了 SQL 注入风险。过去我只把它看成“老师要求的写法”，现在再看，它更像一张很清楚的历史照片：它记录了我当时已经知道数据库怎么用，但还没有真正建立起安全意识。

实验四：Servlet、JSP、Cookie 和 Session 开始互相传球

第四个实验是这组课程里最像一个完整应用的部分：请求进入 Servlet，Servlet 调用 DAO，数据从数据库回来，再交给 JSP 页面展示。学生管理、页面跳转、登录状态、Cookie 和 Session，都在这里第一次同时出现。

我当时最容易迷糊的地方，是不知道一份数据到底应该停在哪一层。页面里能不能直接改数据库？Servlet 里是不是既负责校验又负责拼 HTML？DAO 返回的到底应该是结果集，还是已经整理好的对象？这些问题如果不提前想清楚，代码也不是不能跑，只是每增加一个功能，线就会越缠越紧。

后来我逐渐把流程看成一条传送带：

位置	它在做什么	我当时真正学到的东西
浏览器	提交请求、接收页面	用户看到的只是最后一站
Servlet	接收参数、判断流程	控制器不应该把所有事情都包办
DAO/JDBC	访问数据库、组织结果	数据访问需要和页面逻辑分开
JSP	展示结果	页面主要负责把结果讲给用户看

当然，这个实验里也有明显的旧时代痕迹。比如旧代码里把密码放进 Cookie 的做法，今天看是非常不合适的；它提醒我，能实现登录不等于登录就是安全的。课程代码可以帮助理解机制，但不能直接拿去做真实系统。

分组大作业：从“我能写出来”变成“我们要一起把它接起来”

分组大作业把前面的学生管理继续扩展，里面不再只是一个人的局部练习，而是学生、教师和页面操作一起出现。分组项目和个人实验的最大区别，不在于代码量突然变大，而在于你写的每个接口都可能影响另一个人的部分。

以前自己写实验时，变量名乱一点、页面跳转绕一点，最多是自己多看几眼。到了分组项目里，这些小问题会变成沟通成本。别人要接着你的代码往下写，就必须理解你的命名、目录和数据流。那时我才开始真正体会到，软件工程里的“可读性”不是为了让代码看起来漂亮，而是为了让下一个人敢于修改。

这个项目没有被我重新包装成一个现代框架应用。它仍然是一个有年代感的课程项目，某些页面可能需要旧版 Tomcat、JDBC 驱动和相应的数据库环境才能完整运行。但也正因为保留了这些边界，它更像一份真实的学习记录，而不是后来凭空制造出来的“完美项目”。

把五个部分放在一起，才看得见这条学习路线

单看 UML、文件复制、JDBC 或 JSP，每个实验都像一小块孤立的拼图。把它们按顺序摆起来，我才发现它们其实是在逐步回答同一个问题：一个软件系统是怎样从想法变成可以交互、可以保存数据、也可以被别人继续维护的东西。

UML让我先面对对象和关系；Java 基础实验让我开始处理输入、输出和代码组织；JDBC/DAO把程序和数据接起来；Servlet/JSP让浏览器真正参与进来；分组项目则把“能运行”推进到了“别人也要看得懂、接得上”。

这条路线谈不上多么完整，却很真实。很多后来觉得理所当然的概念，我都是在这些不太漂亮、甚至有些笨拙的课程代码里第一次遇到的。

现在回头看，我最想补上的不是某个 API

如果现在重新做一遍，我会先把数据库配置、异常处理和页面流程画出来，再开始写代码；会把安全问题当成设计的一部分，而不是最后才想起来；也会给每个实验留下一份更清楚的运行记录，而不是只在成功之后松一口气。

但我并不想把当时的代码全部推倒重来。它们的不成熟本身就是实验的一部分：我就是在一次次“为什么页面没有数据”“为什么连接突然失败”“这个逻辑到底应该放哪里”的困惑里，慢慢形成了对后端程序的直觉。

所以，这个仓库对我来说并不只是几份 Java 文件。它记录了我第一次把一个系统从类图、代码、数据库一路接到网页上的过程，也记录了我从“先跑起来再说”，慢慢走向“先想清楚边界和责任”的转变。

如果你对这段课程实验感兴趣，可以直接查看仓库：HIT-JavaEE-Labs。里面的任务书、源码和运行说明都按实验阶段整理好了。

说明：本文根据个人历史实验材料、课程任务和公开仓库整理，部分文字经过 AI 辅助润色；文中代码与结果以仓库实际内容为准。课程资料仅用于学习回顾和个人作品整理，不用于当前课程作业或考试。