※ 引述《gasbomb (虛空雷神獸)》之銘言：
: 大家好, 小弟 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 的, 介紹設計模式的文章
: 不知道大家在遇到這種問題的時候都是如何決策的?
: 如果今天是我的案例, 大家會用哪一種方案解決呢?
原文兩位推文在說的還是DB 實作上的取捨，
OP煩惱的是Anemic model vs behaviorial-rich
model . 我相信你應該有看一些Domain Driven
Design (DDD)的入門？單看你的code 有些詭異：
正常設計不會new Bread().getAll() 去取，
Model 本身不負責update自己（可能你誤解
Anemic model的問題了？）
存取層該是Repository 而不叫DAO 。
回到你的問題，首先你這個”移動category” 的
行為打算放在哪個domain model？假設你有個叫 BreadShop 的model （沒有合用的Model
可以弄個Domain Service, 詳見DDD).
東西大概會長這樣(pseudo code)：
class BreadShop {
void cancelCategory(Category cat, Category moveTo) {
// 假設你Category 有指向它擁有的包
cat.moveBreadsTo(moveTo);
breadCategoryRepo.update(moveTo);
breadCategoryRepo.remove(cat);
//又或者長這樣
breads=breadRepo.findByCategory(cat);
for b in breads
bread.putToCaregory(moveTo);
// 諸如此類
｝
｝
重點是這個動作也是放在Domain 層內，假
設後來你發現真的太慢，也只需要在Repo
內提供bulk update 的功能，但domain 所
Expose 的API 仍然可以維持不變。