方法一
Dao 層有一對多、一對一關聯Service 層寫業務邏輯方法二
Dao 層不寫一對多、一對一關聯，只提供基本的增刪查改Service 層完成關聯查詢等以及寫業務邏輯
方法一在效率上貌似有優勢，但寫 resultMap 和語句真是不開心方法二對程序員比較友好，但效率不如方法一，而且 service 層會比較臃腫
不知道大家的項目中都是如何使用的
個人比較喜歡使用第二種.因為目前所做的項目數據庫表經常需要改動，加字段，而且我本人也是用mybatis generatro自動生成的，可能會覆蓋掉。有沒有什么好的建議?
1 回答
MMTTMM
TA貢獻1869條經驗 獲得超4個贊
LZ的問題，我也思考過，可能是LZ沒遇到過更復雜的業務邏輯，查詢7，8張表的關聯數據，這樣的話，效率就太低了，
還有一種情況是，方法二的的處理明顯的弊端是還要需要自己填充POJO數據，假如POJO的數據結構比較復雜，以后你維護起來自己都蒙蔽，resultMap 多做幾遍就好了，結構很清晰，功能很強大，維護起來也方便。
無論是維護，還是查詢效率，都是需要考慮的，程序員應該辛苦自己，讓自己的程序變的更好
添加回答
舉報
0/150
提交
取消