Fw: [問題] 系統設計

作者: gasbomb (虛空雷神獸)   2019-06-12 17:08:53
※ [本文轉錄自 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 的, 介紹設計模式的文章
不知道大家在遇到這種問題的時候都是如何決策的?
如果今天是我的案例, 大家會用哪一種方案解決呢?
作者: BlacksPig (Black Handsome s Pig)   2019-06-12 17:17:00
或用SQL trigger?
作者: MOONY135 (談無慾)   2019-06-12 18:03:00
我會寫sql的sp吧我覺得商業邏輯寫在要上板的東西寫死了 要改會很麻煩 sp真的比較無痛
作者: x246libra (楓)   2019-06-12 20:01:00
之前上資料庫的人,講者是建議目前開發,都盡量不要用sp
作者: lwtech   2019-06-12 20:07:00
不懂管理和程式的管理,你有沒有用 SP 都一樣
作者: MOONY135 (談無慾)   2019-06-12 20:09:00
可以說一下為什麼不建議的理由嗎 然後替代做法是?
作者: sextitanic   2019-06-12 20:19:00
dao1->更改麵包分類, dao2->刪除麵包分類service->刪除麵包分類, 使用dao1再使用dao2
作者: alan3100 (BOSS)   2019-06-12 22:15:00
SP有cacheplan問題.preparedstatement配framework彈性高
作者: jass970991 (半糖綠假面超人)   2019-06-13 00:02:00
拆兩步就好 dao層還是要有一點彈性 只是談性到哪要決定一下
作者: srwhite (魯蛇阿白)   2019-06-13 12:36:00
同sextitanic 然後service再加個transactionl
作者: ketrobo (貓蘿蔔)   2019-06-13 21:36:00
邏輯正確優先,易讀易維護次之,效能要注意的問題寫在註解裡,驗收過了趕快忘掉這些事大部份你認為兼顧的情況其實都不是真正的兼顧,當那段20%的程式占用80%的系統資源卻無法在時限內完成工作時,你會放棄兼顧,改追求效能,當其他80%的程式碼都不屬於那占用80%系統資源的20%程式碼時,我們也很少有足夠的數據去界定所謂的兼顧
作者: iamshiao (CircleHsiao)   2019-06-14 00:43:00
這不算很複雜的業務邏輯我也會選 sp

Links booklink

Contact Us: admin [ a t ] ucptt.com