Fw: [問題] 系統設計

看板Soft_Job作者 (虛空雷神獸)時間6年前 (2019/06/12 17:08), 編輯推噓4(4推 0噓 18→)
留言22則, 10人參與, 6年前最新討論串1/1
※ [本文轉錄自 java 看板 #1T0C2gIy ] 作者: gasbomb (虛空雷神獸) 看板: java 標題: [問題] 系統設計 時間: Wed Jun 12 17:06:45 2019 大家好, 小弟 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 ※ 發信站: 批踢踢實業坊(ptt.cc) ※ 轉錄者: gasbomb (60.248.96.211 臺灣), 06/12/2019 17:08:53
→
06/12 17:17, 6年前 , 1F
或用SQL trigger?
06/12 17:17, 1F
推
06/12 18:03, 6年前 , 2F
我會寫sql的sp吧
06/12 18:03, 2F
→
06/12 18:16, 6年前 , 3F
我覺得商業邏輯寫在要上板的東西寫死了 要改會很麻煩 sp
06/12 18:16, 3F
→
06/12 18:16, 6年前 , 4F
真的比較無痛
06/12 18:16, 4F
→
06/12 20:01, 6年前 , 5F
之前上資料庫的人，講者是建議目前開發，都盡量不要用s
06/12 20:01, 5F
→
06/12 20:01, 6年前 , 6F
p
06/12 20:01, 6F
→
06/12 20:07, 6年前 , 7F
不懂管理和程式的管理，你有沒有用 SP 都一樣
06/12 20:07, 7F
→
06/12 20:09, 6年前 , 8F
可以說一下為什麼不建議的理由嗎 然後替代做法是？
06/12 20:09, 8F
→
06/12 20:19, 6年前 , 9F
dao1->更改麵包分類, dao2->刪除麵包分類
06/12 20:19, 9F
→
06/12 20:20, 6年前 , 10F
service->刪除麵包分類, 使用dao1再使用dao2
06/12 20:20, 10F
→
06/12 22:15, 6年前 , 11F
SP有cacheplan問題.preparedstatement配framework彈性高
06/12 22:15, 11F
推
06/13 00:02, 6年前 , 12F
拆兩步就好 dao層還是要有一點彈性 只是談性到哪要決
06/13 00:02, 12F
→
06/13 00:02, 6年前 , 13F
定一下
06/13 00:02, 13F
推
06/13 12:36, 6年前 , 14F
同sextitanic 然後service再加個transactionl
06/13 12:36, 14F
→
06/13 21:36, 6年前 , 15F
邏輯正確優先,易讀易維護次之,效能要注意的問題寫在註解
06/13 21:36, 15F
→
06/13 21:36, 6年前 , 16F
裡,驗收過了趕快忘掉這些事
06/13 21:36, 16F
→
06/13 21:55, 6年前 , 17F
大部份你認為兼顧的情況其實都不是真正的兼顧,當那段20
06/13 21:55, 17F
→
06/13 21:55, 6年前 , 18F
%的程式占用80%的系統資源卻無法在時限內完成工作時,你
06/13 21:55, 18F
→
06/13 21:55, 6年前 , 19F
會放棄兼顧,改追求效能,當其他80%的程式碼都不屬於那占
06/13 21:55, 19F
→
06/13 21:55, 6年前 , 20F
用80%系統資源的20%程式碼時,我們也很少有足夠的數據去
06/13 21:55, 20F
→
06/13 21:55, 6年前 , 21F
界定所謂的兼顧
06/13 21:55, 21F
推
06/14 00:43, 6年前 , 22F
這不算很複雜的業務邏輯我也會選 sp
06/14 00:43, 22F
‣ 更多 gasbomb 的文章
文章代碼(AID): #1T0C4cVv (Soft_Job)