看板 java 關於我們 聯絡資訊
大家好, 小弟 java 新手 個人的第一個作品因為缺乏經驗當初做得苦不堪言 肥胖商務層處理完資料後 一行一行的把資料填進 VO 裡面 到了 DAO 又要一行一行的把資料填入 PreparedStatement 寫起來既枯燥又充滿重複的程式碼 後來才了解到這其實是一種 Anemic Domain Model (貧血領域模型) 最近練習刻新系統, 取消商務層的設計只保留部分的 service 讓大部分的邏輯進入物件, 看看可不可以讓自己的系統充血一點 但是現在遇到了一些設計上的問題 假設今天有一家麵包店 ┌───────┐ ┌────┐ │bread_category│ │bread  │ ╞═══════╡ ╞════╡ │cid (PK)←──┼┐│bid (PK)│ │cname     │└┼cid (FK)│ │......    │ │...... │ └───────┘ └────┘ bread 是麵包(廢話) bread_category 是麵包分類 今天的邏輯是 cid 可以刪除 刪除以後該分類下面所有的麵包全部移到未分類 cid = 0 底下 這件事情在 DB 上面做非常簡單, 只要兩行指令就搞定了 UPDATE bread SET cid = 0 WHERE cid = 1; DELETE FROM bread_category WHERE cid = 1; 因為這是 DB 的操作, 所以在 DAO 裡面寫一個方法讓物件使用也是很合理的 但是當我準備這麼作時卻有一種不安的感覺浮上心頭, 覺得自己好像已經破壞了什麼規則 照理說更改麵包分類是事務邏輯, 應該在 model 層處理, DAO 只負責資料存取 從相依性的角度來說, DAO 寫太多東西進去也會加重日後換 DB 的負擔 所以我可能會在 model 這樣寫 new Bread().getAll().stream() .filter(bread -> bread.getCID() == 1) .forEach(bread -> { bread.setCID(0); bread.update(); }); 這樣打開麵包原始碼所有功能一目了然, 日後也方便修改 但是為了刪除一個 cid 叫出所有麵包好像哪裡怪怪的 叫所有麵包一起更新也會占用大量的資料庫連線 (當初沒考慮到大量更新的需求) 為了解決上面的問題在 DAO 另外寫兩個方法 一個是用 cid 查詢麵包 一個是大量更新麵包...... 這樣看起來好像兼顧邏輯跟效能, 可是 DAO 肥大的問題又回來了啊~~~~(崩潰) 而且這樣需要寫的程式更多 那我還不如回去寫那兩行 SQL 指令 雖然我知道這間麵包店可能一輩子都不會有效能瓶頸的問題 不過上面的問題確實已經困擾我一天了 google 找到的也都是一些很 general 的, 介紹設計模式的文章 不知道大家在遇到這種問題的時候都是如何決策的? 如果今天是我的案例, 大家會用哪一種方案解決呢? -- ╔═ ═╦╦═════╦═════╗ ◤◤◤ ╠╣飛鳥ももこ╠═╗ ║ ║╚═════╝ ╚═╦═╣ ║╔══════╗╔═╩═╣ █◤ ╠╣Momoko Asuka╠╝ ║ ◣◢◣◢╩╩══════╩════╝ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.248.96.211 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/java/M.1560330410.A.4BC.html gasbomb:轉錄至看板 Soft_Job 06/12 17:08
LZN: 如果把分類跟麵包的關係用relation table來記錄呢? 06/12 17:34
LZN: 也就是中間多一層table(cid,bid), 然後麵包table的cid移除 06/12 17:35
ssccg: FK直接定義on delete set default就好 06/12 20:06
ssccg: 這是資料模型層的constraint,跟事務邏輯沒關係啊 06/12 20:10
ssccg: 對一個關聯式資料模式來說,刪一筆有被關聯的資料本來就隱 06/12 20:12
ssccg: 含了對關聯資料的處理了 06/12 20:12
haha02: 你可以考慮麵包那邊用on delete set null之類的DB功能 另 06/14 19:34
haha02: 外去調整未分類的查詢邏輯就好 感覺比較簡單 06/14 19:34
haha02: 打完才發現我跟ssccg講的一樣XD 06/14 19:35
jej: 按照你的sql語法去思考 例子中java語法和sql是兩種不同情境 06/15 08:17
jej: 而且category那張表是code mapping去刪除他做啥? 06/15 08:18