smbms 這套項(xiàng)目全稱 Super Market Billing Management System也就是超市訂單管理系統(tǒng)網(wǎng)上傳得很廣的那套 JavaWeb 視頻系列的配套項(xiàng)目就是它。很多人學(xué)完 Servlet、JSP、Filter、JDBC 之后面對的完整體項(xiàng)目就是這套。我當(dāng)年也是一集一集跟著敲敲完發(fā)現(xiàn)一個很現(xiàn)實(shí)的問題跟著視頻能在本地跑起來合上視頻讓我自己從零寫一遍連包結(jié)構(gòu)都理不清。后來我把視頻丟到一邊只留題目和功能要求完整地復(fù)現(xiàn)了一遍。這篇文章就是那次復(fù)現(xiàn)的完整記錄環(huán)境、數(shù)據(jù)庫、分層代碼、登錄權(quán)限、分頁查詢、增刪改查、部署驗(yàn)證每一步我都盡量把背后的原因說清楚。1. 項(xiàng)目定位與拆解這個經(jīng)典項(xiàng)目到底在訓(xùn)練什么1.1 業(yè)務(wù)模型超市、供應(yīng)商和訂單先理解業(yè)務(wù)。這個系統(tǒng)模擬的是一家超市的采購訂單管理流程超市會從多家供應(yīng)商進(jìn)貨每筆進(jìn)貨對應(yīng)一張訂單訂單上記錄商品名、規(guī)格、數(shù)量、金額、是否已付款同時(shí)還要記錄這張訂單對應(yīng)哪家供應(yīng)商。管理人員打開系統(tǒng)能看到所有訂單也能按商品名、供應(yīng)商、付款狀態(tài)篩選還要能新增、修改、刪除訂單。供應(yīng)商和用戶則是輔助管理模塊供應(yīng)商要維護(hù)聯(lián)系人、電話、地址、傳真用戶要區(qū)分角色普通員工和管理員看到的界面、能做的操作不一樣。業(yè)務(wù)不復(fù)雜但剛好能把一套入門級管理系統(tǒng)的完整鏈路覆蓋到從數(shù)據(jù)庫表設(shè)計(jì)到后臺接口再到前端頁面展示和交互每一環(huán)都不缺。對于剛學(xué)完 JavaWeb 基礎(chǔ)的人來說它不像電商系統(tǒng)那樣龐大也不像課后作業(yè)那樣單薄是那種跳一跳正好夠得著的項(xiàng)目。1.2 功能清單與學(xué)習(xí)目標(biāo)登錄、退出登錄登錄后根據(jù)角色顯示對應(yīng)菜單用戶管理新增、修改、刪除、模糊查詢、角色篩選、分頁供應(yīng)商管理新增、修改、刪除、查看訂單管理新增、修改、刪除、組合條件查詢、分頁密碼修改校驗(yàn)舊密碼更新新密碼對應(yīng)到技術(shù)點(diǎn)清單就是下面這張表技術(shù)點(diǎn)在項(xiàng)目里的落點(diǎn)Maven依賴管理、war 打包、目錄規(guī)范Servlet所有請求入口處理參數(shù)、轉(zhuǎn)發(fā)/重定向JSP EL JSTL頁面展示、列表循環(huán)、分頁條Filter登錄攔截、字符編碼統(tǒng)一處理JDBC 封裝BaseDao、數(shù)據(jù)庫連接、增刪改查MySQL四張核心表、多表聯(lián)查這套項(xiàng)目最有價(jià)值的地方就在這里它沒有引入任何框架你能看到 Servlet 最原始的工作狀態(tài)也能自己動手寫出一個能用的 JDBC 封裝層。之后再學(xué) Spring Boot 或 MyBatis你會更容易理解框架到底幫你省掉了什么。2. 環(huán)境與開局版本組合選對了后面少踩一半坑我復(fù)現(xiàn)時(shí)用的環(huán)境組合是這批項(xiàng)目最常見的一檔JDK 8、Maven 3.6.3、Tomcat 8.5、MySQL 8.0。說實(shí)話現(xiàn)在裝 JDK 17 的人很多但老項(xiàng)目代碼大多是給 JDK 8 設(shè)計(jì)的如果直接上 JDK 17Tomcat 的版本、編譯級別、依賴的舊 jar 都可能出兼容問題第一輪排查就能耗掉半天。所以第一次復(fù)現(xiàn)建議直接按 JDK 8 來跑通以后再考慮升級。2.1 我用的那套穩(wěn)定組合JDK 1.8和主流的 Web 容器、視頻教程里的配置完全對得上Maven 3.6.xIDEA 自帶版本通常也能用注意配好本地倉庫和鏡像源Tomcat 8.5支持 Servlet 3.1對老項(xiàng)目兼容性好MySQL 8.0需要注意驅(qū)動類和時(shí)區(qū)參數(shù)下文會細(xì)說IDEA社區(qū)版就能跑 Web 項(xiàng)目專業(yè)版只是多了框架支持有個細(xì)節(jié)我想提一下如果本機(jī)已經(jīng)裝了更高版本的 Tomcat比如 Tomcat 10那要特別注意它默認(rèn)使用的是 jakarta.servlet 命名空間老項(xiàng)目里的 javax.servlet 全部要改包名。對初學(xué)者來說這是個大坑不建議在第一步就挑戰(zhàn)它。2.2 pom.xml 依賴與兩個容易出錯的點(diǎn)先看依賴。Maven 工程的第一步是創(chuàng)建 war 包結(jié)構(gòu)的 Web 項(xiàng)目然后在 pom.xml 里加上核心依賴dependencies !-- Servlet APITomcat 已提供所以用 provided -- dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency dependency groupIdjavax.servlet.jsp/groupId artifactIdjavax.servlet.jsp-api/artifactId version2.3.3/version scopeprovided/scope /dependency !-- JSTLJSP 頁面里做列表循環(huán)和條件判斷 -- dependency groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency !-- MySQL 驅(qū)動 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency /dependencies依賴?yán)镒钊菀壮鰡栴}的就是 MySQL 驅(qū)動。MySQL 5.x 用 com.mysql.jdbc.Driver而 MySQL 8.x 必須改成 com.mysql.cj.jdbc.Driver否則啟動時(shí)會報(bào) ClassNotFoundException。第二個坑是連接串MySQL 8 默認(rèn)要求帶上時(shí)區(qū)參數(shù)所以連接地址通常寫成這樣jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/smbms?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 jdbc.usernameroot jdbc.password123456characterEncodingutf8 這個參數(shù)也不能漏否則后面插入的中文數(shù)據(jù)到數(shù)據(jù)庫里全是問號。2.3 IDEA 建 Web 工程時(shí)的 Artifact 問題這一步是新手最容易卡住的地方而且卡得很莫名其妙工程建好了代碼寫完了一點(diǎn)運(yùn)行瀏覽器直接 404控制臺沒報(bào)錯。原因多半是 IDEA 里沒有配置好 Web Artifact。正確流程是這樣的用 Maven 創(chuàng)建工程時(shí)選 webapp 骨架沒有骨架也可以后面手動加 Web 模塊然后在 Project Structure 里把模塊的 Web Facet 關(guān)聯(lián)上再在 Artifacts 里新增一個 war exploded 類型的啟動產(chǎn)物最后在 Tomcat Run Configuration 的 Deployment 頁面把這個 Artifact 添加進(jìn)去設(shè)置 Application context 為 /smbms。只要這幾步對齊Tomcat 啟動后能直接訪問 http://localhost:8080/smbms/。實(shí)測下來社區(qū)版和新版 IDEA 的界面長得不太一樣但核心套路沒變。如果啟動后 index.jsp 都訪問不了優(yōu)先檢查Artifacts 是否為空、context 路徑是否寫對、Tomcat 的 application server 是否已經(jīng)配置。3. 數(shù)據(jù)先行四張表的字段設(shè)計(jì)和容易忽略的小細(xì)節(jié)代碼還沒寫先把數(shù)據(jù)表建好。smbms 的核心是四張表角色表、用戶表、供應(yīng)商表和訂單表。我復(fù)現(xiàn)時(shí)按項(xiàng)目常見的字段結(jié)構(gòu)來建這也是整個系統(tǒng)最底層的部分。3.1 四張表的字段設(shè)計(jì)用戶表是最復(fù)雜的字段也比較多字段類型說明idint主鍵自增userCodevarchar用戶編碼登錄時(shí)用userNamevarchar真實(shí)姓名userPasswordvarchar密碼建議存 MD5genderint性別1 男 0 女birthdaydate出生日期phonevarchar電話addressvarchar地址userRoleint角色 id對應(yīng) smbms_role 表createdByint創(chuàng)建人 idcreationDatedatetime創(chuàng)建時(shí)間modifyByint最后修改人 idmodifyDatedatetime最后修改時(shí)間角色表很簡單id、roleCode、roleName一般就是管理員和普通員工。供應(yīng)商表 smbms_provider 包含供應(yīng)商編碼、名稱、描述、聯(lián)系人、電話、地址、傳真以及創(chuàng)建人、創(chuàng)建時(shí)間。訂單表 smbms_bill 是核心業(yè)務(wù)表包含訂單編碼、商品名、商品描述、計(jì)量單位、數(shù)量、總價(jià)、是否付款、供應(yīng)商 id以及創(chuàng)建和修改相關(guān)字段。字段命名看起來瑣碎但很有必要。createdBy、modifyBy 這些字段在后面的修改記錄功能里要用很多網(wǎng)上代碼為了省事刪掉了它們結(jié)果后來要追蹤數(shù)據(jù)變更就只能干瞪眼。3.2 外鍵不建物理外鍵的原因四張表之間有明顯的關(guān)聯(lián)關(guān)系用戶表 userRole 指向角色表 id訂單表 providerId 指向供應(yīng)商表 id。很多新手會想既然有關(guān)聯(lián)那就加上外鍵約束吧。實(shí)際項(xiàng)目里這套項(xiàng)目的常見做法是不建物理外鍵只做邏輯外鍵也就是字段值存在對應(yīng)關(guān)系但數(shù)據(jù)庫層面不強(qiáng)制約束。原因有二第一物理外鍵在刪除和更新時(shí)會帶來額外的約束判斷項(xiàng)目里我們刪除供應(yīng)商前要先檢查有沒有關(guān)聯(lián)訂單這個邏輯放在 Service 層控制更好提示也更友好第二邏輯外鍵讓拆庫、遷移、分表都更容易教學(xué)中也能更自然地引出 left join 聯(lián)查。如果你是在自己練手想加物理外鍵學(xué)習(xí)約束概念也沒問題但在 smbms 這個項(xiàng)目里跟著主流做法走邏輯外鍵更省事。3.3 初始化數(shù)據(jù)與密碼存儲建完表一定要準(zhǔn)備初始化數(shù)據(jù)不然后面聯(lián)調(diào)全是空列表分頁、篩選都看不出效果。我放了 3 個用戶、2 家供應(yīng)商和 8 條訂單數(shù)據(jù)量剛好覆蓋兩頁方便測分頁邊界。密碼存儲這里要單獨(dú)說一句。網(wǎng)上很多版本的 smbms 代碼里密碼是明文存的演示而已。但你自己做項(xiàng)目時(shí)建議至少封裝一個 MD5Util把密碼加密后入庫登錄時(shí)先把用戶輸入的密碼 MD5 化再比對。這不是 smbms 要求的功能但這是一道安全底線練手項(xiàng)目也不能把明文密碼寫死在數(shù)據(jù)庫里。4. 骨架落地分層目錄、BaseDao 和基礎(chǔ)件先搭好環(huán)境就緒、表也建好了接下來是最重要的一步把代碼骨架搭起來。很多新手寫項(xiàng)目不講究包結(jié)構(gòu)所有類全堆在一起前期沒問題寫到訂單模塊自己都找不到 Service 在哪。我建議從一開始就按分層結(jié)構(gòu)來后面每個模塊的代碼都能精確落到對應(yīng)位置。4.1 包結(jié)構(gòu)與請求走向我用的包結(jié)構(gòu)是這樣的com.xxx.smbms ├── pojo // 實(shí)體類User、Role、Provider、Bill、PageSupport ├── dao // 數(shù)據(jù)訪問接口 impl 實(shí)現(xiàn) ├── service // 業(yè)務(wù)接口 impl 實(shí)現(xiàn) ├── servlet // 控制層LoginServlet、UserServlet、ProviderServlet、BillServlet ├── filter // 過濾器UniversalFilter、LoginFilter └── util // 工具類JDBCUtil、MD5Util、常量類請求走向也很直白瀏覽器請求某個 Servlet → Servlet 接收參數(shù)、調(diào) Service → Service 調(diào) DAO → DAO 操作 MySQL → 結(jié)果一層層返回 → Servlet 把數(shù)據(jù)塞進(jìn) request 或 session → 轉(zhuǎn)發(fā)到 JSP 頁面渲染。一開始可能覺得分這么多層太繞但你要理解每一層的職責(zé)Servlet 不寫 SQLDAO 不寫業(yè)務(wù)判斷Service 不直接處理參數(shù)。好處是以后換數(shù)據(jù)庫、換前端、加緩存只需要動對應(yīng)的一層。這套結(jié)構(gòu)其實(shí)就是后面 Spring 分層思想的雛形。4.2 數(shù)據(jù)庫工具類和 BaseDao 的作用JDBC 最麻煩的就是重復(fù)的加載驅(qū)動、建連接、釋放資源。我參考網(wǎng)上常見寫法先寫一個 BaseDao把通用邏輯收斂起來public class BaseDao { // 加載驅(qū)動 獲取連接 public static Connection getConnection() throws Exception { return JDBCUtil.getConnection(); } // 通用增刪改支持可變參數(shù) public static int executeUpdate(Connection conn, String sql, Object... params) throws Exception { PreparedStatement ps conn.prepareStatement(sql); for (int i 0; i params.length; i) { ps.setObject(i 1, params[i]); } int result ps.executeUpdate(); closeAll(conn, ps, null); return result; } // 通用查詢返回 ResultSet 由 DAO 層自行封裝 public static ResultSet executeQuery(Connection conn, String sql, Object... params) throws Exception { PreparedStatement ps conn.prepareStatement(sql); for (int i 0; i params.length; i) { ps.setObject(i 1, params[i]); } return ps.executeQuery(); } // 釋放資源 public static void closeAll(Connection conn, PreparedStatement ps, ResultSet rs) throws Exception { if (rs ! null) rs.close(); if (ps ! null) ps.close(); if (conn ! null) conn.close(); } }這里有一個容易被忽略的點(diǎn)查詢返回的 ResultSet 不能立刻關(guān)閉連接和 PreparedStatement因?yàn)榉庋b ResultSet 還需要時(shí)間。所以我一般不在 executeQuery 方法里直接 closeAll而是讓 DAO 層在拿到結(jié)果、封裝成對象之后再調(diào)用 closeAll 關(guān)閉。很多新手在 BaseDao 里統(tǒng)一關(guān)閉資源結(jié)果一跑就報(bào)ResultSet already closed這個坑我踩過。4.3 接口加實(shí)現(xiàn)這個習(xí)慣值得堅(jiān)持雖然項(xiàng)目很小但我建議 DAO 和 Service 都寫成接口 實(shí)現(xiàn)類的形式比如 UserDao 接口下有 UserDaoImpl。理由不是規(guī)范這種空話而是等你想把 JDBC 換成 MyBatis 的時(shí)候只需要重新寫一套 DAO 實(shí)現(xiàn)類Servlet 和 Service 層完全不用動。我后面把 smbms 遷移到 MyBatis 時(shí)深刻體會到這個設(shè)計(jì)有多省事。前端 JSP 頁面里取值依賴實(shí)體類的 getter/setter 規(guī)范pojo 類里字段名和頁面調(diào)用名要保持一致這里踩過坑的人不少。5. 登錄主鏈路Session、Filter 和角色控制登錄模塊是整個系統(tǒng)最先要跑的鏈路也是后面所有模塊的入口。只要登錄和攔截做好整個系統(tǒng)的骨架就穩(wěn)了。5.1 登錄流程與密碼比對登錄頁收集 userCode 和 userPassword提交到 UserServlet 的 login 方法。Servlet 先做簡單的空值校驗(yàn)然后調(diào)用 Service 層按 userCode 查詢用戶拿回 user 對象后比對密碼。這里要注意如果數(shù)據(jù)庫里存的是 MD5那么比對前要把用戶輸入密碼也 MD5 化一次不能拿明文直接和密文比較。登錄成功的處理也有講究。我把 user 對象放進(jìn) session而不是只放一個 userId這樣 JSP 頁面里可以直接用 ${sessionScope.user.userName} 顯示當(dāng)前登錄人也能隨時(shí)通過 user.userRole 判斷角色。登錄失敗時(shí)向前端返回錯誤信息轉(zhuǎn)發(fā)回 login.jsp在頁面用 EL 表達(dá)式回顯錯誤內(nèi)容。5.2 Filter 攔截和靜態(tài)資源放行如果登錄流程寫完了但沒有加 Filter那么只要知道接口地址不登錄也能直接訪問所有頁面。smbms 里最常見的寫法是建一個 LoginFilter作用于所有請求在 doFilter 里判斷public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; String uri request.getRequestURI(); if (uri.endsWith(.css) || uri.endsWith(.js) || uri.endsWith(.jpg) || uri.endsWith(.png) || uri.endsWith(login.jsp) || uri.endsWith(login)) { chain.doFilter(request, response); return; } HttpSession session request.getSession(false); if (session ! null session.getAttribute(user) ! null) { chain.doFilter(request, response); } else { response.sendRedirect(request.getContextPath() /login.jsp); } }靜態(tài)資源放行這個細(xì)節(jié)特別容易漏如果你直接攔所有請求登錄頁的 css、js 全部加載不出來頁面會變成光禿禿的 HTML。判斷關(guān)鍵詞可以再完整一點(diǎn)比如還要放行登錄時(shí)的驗(yàn)證碼接口等。在 smbms 里沒有注冊所以放行 login 相關(guān)的路徑就夠了。如果你用的是注解方式配置 Filter比如 WebFilter(/*)注意要和 Servlet 的 URL 映射區(qū)分開。Filter 攔的是請求路徑Servlet 的 WebServlet 注解定義的是功能入口兩者配合使用不要互相覆蓋。5.3 退出登錄與角色權(quán)限退出登錄比較簡單調(diào)用 session.invalidate() 把整個會話廢掉然后重定向到 login.jsp。這里不要去手動 removeAttribute因?yàn)?session 里可能還存了分頁參數(shù)、條件參數(shù)不清理干凈容易殘留。角色權(quán)限這塊smbms 的常見實(shí)現(xiàn)是JSP 導(dǎo)航菜單里用 JSTL 判斷當(dāng)前登錄用戶的 userRole如果 roleId 是管理員顯示用戶管理入口普通員工則只顯示訂單和供應(yīng)商模塊。后臺也需要做一個簡單的校驗(yàn)比如刪除用戶這個操作如果不是管理員登錄直接拒絕。雖然在教學(xué)項(xiàng)目里前端隱藏菜單已經(jīng)夠用但補(bǔ)上后臺校驗(yàn)會讓你對權(quán)限控制有更完整的理解。6. 列表頁與分頁查詢用戶、訂單共用的一套套路看完登錄接下來是整個項(xiàng)目里最肥的一塊列表和分頁。用戶管理、供應(yīng)商管理、訂單管理都有列表頁而且都支持條件查詢和分頁。這一套邏輯想明白了后面三個模塊可以復(fù)制粘貼著寫。6.1 分頁參數(shù)和 Page 對象分頁本身不復(fù)雜但參數(shù)多理清關(guān)系很重要。需要四個數(shù)totalCount 總記錄數(shù)、pageSize 每頁條數(shù)、currentPageNo 當(dāng)前頁、totalPageCount 總頁數(shù)。int totalCount userDao.getUserCount(userName, roleId); int pageSize 5; int totalPageCount (totalCount pageSize - 1) / pageSize; int currentPageNo 1; String pageIndex request.getParameter(pageIndex); if (pageIndex ! null !.equals(pageIndex)) { currentPageNo Integer.parseInt(pageIndex); } if (currentPageNo 1) currentPageNo 1; if (currentPageNo totalPageCount totalPageCount 0) currentPageNo totalPageCount; int begin (currentPageNo - 1) * pageSize;總頁數(shù)的計(jì)算公式 (totalCount pageSize - 1) / pageSize 是向上取整的意思這樣 8 條數(shù)據(jù)每頁 5 條算出來就是 2 頁而不是 1 頁。這個邊界細(xì)節(jié)很多人會在寫代碼的時(shí)候栽一跤。我把這四個參數(shù)連同查詢列表一起封裝成一個 PageSupport 對象放回 request 里JSP 頁面統(tǒng)一取 pageSupport.totalPageCount、pageSupport.currentPageNo 這樣的屬性。這種對象化封裝的好處是不同模塊的頁面模板長得一樣改樣式只需改一處。6.2 動態(tài) SQL 拼接與條件回顯列表?xiàng)l件查詢的核心在 DAO 層。以用戶管理為例支持按姓名模糊查詢、按角色篩選SQL 要動態(tài)拼接StringBuilder sql new StringBuilder( select u.*, r.roleName from smbms_user u left join smbms_role r on u.userRole r.id where 11); ListObject params new ArrayList(); if (userName ! null !.equals(userName)) { sql.append( and u.userName like ?); params.add(% userName %); } if (roleId 0) { sql.append( and u.userRole ?); params.add(roleId); } sql.append( order by u.creationDate desc limit ?, ?); params.add(begin); params.add(pageSize);where 11 這種寫法老項(xiàng)目里很常見好處是不管有沒有條件后面的 and 都能直接接上去不用費(fèi)心去判斷是否拼接了第一個條件。條件回顯是另一個坑。翻頁的時(shí)候如果只把 pageIndex 傳給后端userName 和 roleId 沒有傳那么第二頁的數(shù)據(jù)就變成了沒有查詢條件的全部數(shù)據(jù)。我最初的實(shí)現(xiàn)就是直接在超鏈接里拼 URL結(jié)果中文姓名在地址欄里會亂碼。后來我改成在 JSP 里放一個隱藏表單分頁按鈕先用 JS 往隱藏字段里寫入當(dāng)前篩選條件再提交這樣既不會亂碼也保住了條件。這是一個很典型的頁面上沒報(bào)錯數(shù)據(jù)卻不對的隱蔽 bug排查起來很費(fèi)神。6.3 訂單模塊的組合查詢訂單管理比用戶管理多兩個查詢條件商品名、供應(yīng)商、是否付款。邏輯和用戶管理一樣只是 SQL 里多幾個判斷if (productName ! null !.equals(productName)) { sql.append( and b.productName like ?); params.add(% productName %); } if (providerId 0) { sql.append( and b.providerId ?); params.add(providerId); } if (isPayment 0) { sql.append( and b.isPayment ?); params.add(isPayment); }訂單列表還會帶出供應(yīng)商名稱所以要用 left join smbms_provider。寫到這里想提醒一句查詢列表和查詢總條數(shù)這兩條 SQL 一定要保持一致。常見情況是列表 SQL 里加了一個條件統(tǒng)計(jì)總數(shù)的 SQL 忘加結(jié)果就是頁面頂部顯示共 20 條翻頁卻只有 10 條。我在復(fù)現(xiàn)時(shí)真真切切踩過后來把查 count 和查 list 的兩個方法放在一起維護(hù)每次改條件都同步改兩個方法。7. 供應(yīng)商與訂單的增刪改那些容易漏掉的細(xì)節(jié)列表和分頁打通之后剩下的就是新增、修改、刪除這幾個動作。這幾個動作看起來是 CRUD 的機(jī)械重復(fù)但里面藏著不少不寫一遍就不會注意的細(xì)節(jié)。7.1 先查關(guān)聯(lián)再刪除供應(yīng)商數(shù)據(jù)的刪除是最容易破壞數(shù)據(jù)完整性的操作。如果某個供應(yīng)商下已經(jīng)存在訂單直接 delete provider那么訂單表里這個 providerId 就變成孤數(shù)據(jù)了。所以刪除前一定要先查訂單表int billCount billDao.getBillCountByProviderId(providerId); if (billCount 0) { // 返回該供應(yīng)商下存在訂單不能刪除 } else { providerDao.deleteProviderById(providerId); }這個邏輯看起來簡單但它觸及了一個非常本質(zhì)的問題業(yè)務(wù)層面的完整性校驗(yàn)不能完全依賴數(shù)據(jù)庫約束。外部系統(tǒng)、批處理腳本、管理后臺都可能繞過頁面直接操作數(shù)據(jù)所以在 Service 層主動做約束校驗(yàn)是最通用的兜底方案。7.2 修改時(shí)的 created/modify 字段網(wǎng)上很多版本的表單修改只更新業(yè)務(wù)字段比如用戶名、電話、地址完全不碰 createdBy、modifyBy、creationDate、modifyDate。這會導(dǎo)致一個問題數(shù)據(jù)明明被改過了卻沒有任何痕跡。我建議修改操作至少做到兩點(diǎn)更新 modifyBy 為當(dāng)前登錄用戶 id更新 modifyDate 為當(dāng)前時(shí)間新增操作則要填 createdBy 和 creationDate。這可以說是把表設(shè)計(jì)的價(jià)值真正用起來。用戶表還有一個特別容易翻車的字段birthday。前端日期選擇器提交的格式是 yyyy-MM-dd后端如果直接往 DATE 字段里 setString有些驅(qū)動版本會報(bào)類型轉(zhuǎn)換錯誤。穩(wěn)妥做法是在 Servlet 里先 SimpleDateFormat 解析成 java.util.Date再通過 PreparedStatement.setDate 轉(zhuǎn)成 java.sql.Date 傳入。字符串和日期類型的轉(zhuǎn)換是 CRUD 模塊里新手報(bào)錯最多的地方之一。7.3 Ajax 刪除訂單一個值得嘗試驗(yàn)證的前后端交互smbms 的訂單刪除環(huán)節(jié)很適合用來演示最簡單的 Ajax。頁面點(diǎn)擊刪除按鈕后用 jQuery 發(fā) POST 請求到 BillServlet 的 del 方法后端刪除成功后返回字符串 success前端根據(jù)返回結(jié)果刷新頁面。function deleteBill(id) { if (confirm(確定刪除這條訂單嗎)) { $.post(${pageContext.request.contextPath}/bill.do, { method: del, id: id }, function (res) { if (res success) { location.reload(); } else { alert(res); } } ); } }對應(yīng) Servlet 端最后就是response.getWriter().write(success)。這個動作本身不難但它是前端異步請求、后端返回字符串、前端局部刷新的雛形。如果你后面要做前后端分離這個小小的 Ajax 交互就是第一個熱身。我遇到的坑是Servlet 跳轉(zhuǎn)和返回普通文本的邊界。刪除成功后如果代碼里不小心寫了response.sendRedirectAjax 拿到的就不是 success 而是頁面內(nèi)容回調(diào)函數(shù)永遠(yuǎn)走不到正確分支。所以后端在處理 Ajax 請求時(shí)只寫數(shù)據(jù)不做頁面跳轉(zhuǎn)。8. 部署到 Tomcat從本地到瀏覽器首訪的驗(yàn)證步驟代碼寫完最后一步是把項(xiàng)目部署到 Tomcat 上真正通過瀏覽器訪問。這一步對新手來說往往比寫代碼更折磨因?yàn)槌鰡栴}的時(shí)候控制臺不一定會報(bào)錯頁面就給你一個 404 或 500。8.1 war 包與 IDEA 集成 Tomcat有兩種部署方式可以選。第一種是直接用 Maven 構(gòu)建 war 包扔到 Tomcat 的 webapps 目錄下啟動 Tomcat 后會自動解壓部署。第二種是在 IDEA 里配置 Tomcat Servlet用 war exploded 部署開發(fā)時(shí)改代碼能更快見效果。我建議先學(xué)會方式二配合 IDEA 調(diào)試斷點(diǎn)能直接打在 Servlet 代碼上排查問題效率高。具體配置路徑前面已經(jīng)說過關(guān)鍵點(diǎn)在于 Artifacts 要和 Web Facet 關(guān)聯(lián)缺了這一步Tomcat 能啟動但找不到頁面。8.2 常見部署報(bào)錯對照表把我在復(fù)現(xiàn)過程中遇到的幾類高頻問題整理成了一張表現(xiàn)象可能原因處理方式ClassNotFoundException: com.mysql.cj.jdbc.DriverMySQL 驅(qū)動沒引入或版本舊檢查 pom.xml 和 war 的 lib 目錄Access denied for user rootlocalhost賬號密碼不對或未授權(quán)檢查 jdbc.properties頁面 404Artifact 配置缺失/context 路徑不對檢查 IDEA 部署配置和訪問路徑中文亂碼缺少字符集過濾器或數(shù)據(jù)庫連接串沒配編碼加 Filter檢查 url 的 characterEncodingPort 8080 already in use端口被占用改端口或結(jié)束占用進(jìn)程ResultSet already closed查詢后提前關(guān)閉了連接按 BaseDao 的關(guān)閉順序調(diào)整字符集這個問題值得展開一下。除了數(shù)據(jù)庫連接串的編碼參數(shù)代碼里通常還會有一個字符集過濾器在 doFilter 里執(zhí)行request.setCharacterEncoding(UTF-8)和response.setCharacterEncoding(UTF-8)。如果漏掉這個 Filter表單提交的中文數(shù)據(jù)會在進(jìn)入 Servlet 之前就亂掉后面再怎么處理都救不回來所以它必須放在請求處理的最前面。8.3 每次啟動前的小檢查清單部署次數(shù)多了之后我養(yǎng)成了一個習(xí)慣每次啟動前花十秒鐘過一遍這三項(xiàng)。第一jdbc.properties 里的賬號密碼是否正確MySQL 服務(wù)有沒有啟動第二Tomcat 端口是否被占用第三數(shù)據(jù)庫里有沒有初始化數(shù)據(jù)。八成的問題都出在這三件事上。如果你訪問的是 login.jsp但頁面里引用的 css、js 路徑全是 /css/xxx 這種絕對路徑就會出現(xiàn)樣式丟失。因?yàn)椴渴鸷箜?xiàng)目名是 smbms正確的路徑應(yīng)該是 /smbms/css/xxx。最穩(wěn)妥的寫法是在所有 JSP 頁面統(tǒng)一用${pageContext.request.contextPath}拼路徑這樣不管部署在哪個 context 下都不會錯。9. 跑通之后還能怎么走往 MyBatis 與 Spring 生態(tài)遷移smbms 完全跑通以后等于你親手徒手搭了一個 JavaWeb 應(yīng)用。這時(shí)候千萬別急著把它丟到一邊它是最好的進(jìn)化素材。9.1 替換 DAO把 JDBC 換成 MyBatis我做的第一個改造是把原生 JDBC 的 DAO 實(shí)現(xiàn)替換成 MyBatis。因?yàn)榍懊媪袅?DAO 接口所以 Servlet 和 Service 層幾乎不用改只需要寫新的 mapper 文件和實(shí)現(xiàn)類然后把 Service 里 new 出來的 DAO 實(shí)現(xiàn)類換成 MyBatis 版本。這個改造過程會讓你真正理解 ORM 框架省掉的到底是什么連接管理、SQL 執(zhí)行、結(jié)果集到對象的映射。寫一遍之后你再去看 MyBatis 的動態(tài) SQL會發(fā)現(xiàn)和你在 smbms 里手寫的 if 拼接邏輯一模一樣。當(dāng)然遷移過程中也有幾個容易翻車的點(diǎn)。MyBatis 的if testuserName ! null and userName ! 判斷邏輯要和原 JDBC 版本保持一致比如模糊查詢里是否拼接 like、% 放在哪一邊這些細(xì)節(jié)不對就會查出完全不同的結(jié)果。另外分頁的 limit 參數(shù)在 MyBatis 里要顯式標(biāo)注類型不然某些驅(qū)動會報(bào)參數(shù)類型不明確這類問題排查起來往往要靠翻日志。9.2 前后端分離與 Spring 化smbms 作為腳手架的價(jià)值再進(jìn)一步可以把 JSP 全部換成純前端頁面后端只提供 JSON 接口。登錄、分頁、模糊查詢這些功能你已經(jīng)知道怎么做只是把返回格式從 JSP 頁面變成 JSON 字符串。這個練習(xí)做完了Spring Boot 里最基礎(chǔ)的 Controller 寫法對你來說就沒有任何神秘感。如果還不滿足后面也可以把 Servlet 替換成 Spring MVC把 Service 交給 Spring 容器管理。這樣一套遷移走下來你等于用 smbms 這個骨架把整個 JavaWeb 進(jìn)化史重走了一遍。我后來把這次復(fù)現(xiàn)的代碼給過幾個新人參考他們問得最多的其實(shí)不是登錄或者分頁而是動態(tài) SQL 拼接那段到底為什么這么寫。遇到這種情況我的建議永遠(yuǎn)只有一個別急著背把拼接出來的 SQL 打印到控制臺對照日志看一遍比對著屏幕猜十遍都有用。這一步做完smbms 對你就不是一個視頻里跑過的項(xiàng)目而是真正屬于你自己的第一份 JavaWeb 工程了。