這個應該算是在 Rails 蠻常見的做法，不過近期在思考 UseCase 情境的設計時，覺得實作一個 Validator 即可，倒是很多框架會把輸入的驗證設計在 Middleware 裡面，可能是個不太好的做法，一但換框架可能就失去所有驗證機制了⋯⋯
Form - 重新思考 Rails 架構
Form - 重新思考 Rails 架構
其實我蠻喜歡spring 的bean validation
把validation 做在form object 的class上
把validation 做在form object 的class上
但那就跟你說的一樣 他是annotation based 把中間的magic拿掉 就只是POJO
這問題真的很難，我自己蠻喜歡 annotation 的做法，但是只要一離開框架他就瞬間就殘廢了 XD
目前是在抓怎麼去區分哪些物件適合這樣做，至少照 Clean Architecture / Domain-Driven Design 的想法去看，應該會有一個界線在，哪些要用 Plain Object 去做，哪些可以靠 Library / Framework 去解
應該會有一個平衡點可以找到，但這就很吃經驗了，我剛好最近比較常遇到
目前是在抓怎麼去區分哪些物件適合這樣做，至少照 Clean Architecture / Domain-Driven Design 的想法去看，應該會有一個界線在，哪些要用 Plain Object 去做，哪些可以靠 Library / Framework 去解
應該會有一個平衡點可以找到，但這就很吃經驗了，我剛好最近比較常遇到
最近也有另一個有趣的情境，那是一段商業邏輯，從資料庫啦出來後組完後，要用 Weight-based 去找 Best Match 是哪個，理論上我只要用 MinHeap / MaxHeap 去保存就好，但是他是商業邏輯，我似乎不該靠一些外部套件去解決，這個 Heap 演算法應該是在我的 Domain Knowledge 裡面（而且很簡單）
這樣到底該不該讓一個外部套件污染我的 Domain Knowledge 完整性，就變成一個取捨問題（目前是偏好不要，然後終於頓悟演算法跟資料結構到底在哪裡需要應用 XD）
這樣到底該不該讓一個外部套件污染我的 Domain Knowledge 完整性，就變成一個取捨問題（目前是偏好不要，然後終於頓悟演算法跟資料結構到底在哪裡需要應用 XD）