努力設計，實施和維護CRUD

Question

您在您的數據訪問層中實現和維護簡單的創建，讀取，更新和刪除（CRUD）方法所花費的總體開發工作量的百分比是多少？

遷移到像Hibernate或Entity Framework這樣的ORM是否導致顯着的節省？ 有什麼設計的氣味讓你知道什麼時候移動到ORM爲你的數據訪問層是一個不錯的選擇？

親切的問候， 阿希什

Answer 1

最近剛剛花費的時間（大概40％左右）複製什麼的ORM會在幾分鐘內已經做了可笑的數字，我不得不說，只要你能允許井測試框架來生成（並保持！）基本的CRUD操作，讓它做到！

讓框架做到它擅長的地方。花你的時間在應用程序中真正增加價值的部分，即你正在解決的業務問題。只有在框架不足的情況下，你才能真正考慮解決這個問題。 「落後」可能包括性能，但通常在框架中有「掛鉤和旋鈕」，可以讓你做你需要做的事情。

實現/設計氣味：當你編碼第40屆時間「StoredProcedureWrapper」或通過捕捉DAO輸出正在實施的查詢結果緩存，你起碼/早該使用ORM

憑藉的Ruby/Rails或Groovy/Grails類型的框架，我看不到真正的原因不是以ORM層開始，因爲兩個環境都爲您生成域。使用Spring/Hibernate，它稍微複雜一些，但仍然節省了很多類似小類的手工編碼。

我也是在幾個項目發現，在過去的10年左右，如果我們不開始使用ORM，我們最終制定或「盜竊」 JDBC框架或其他腳手架代碼，再次重複了很多什麼是ORM可以給你帶來什麼。