方法一
Dao 层有一对多、一对一关联Service 层写业务逻辑方法二
Dao 层不写一对多、一对一关联,只提供基本的增删查改Service 层完成关联查询等以及写业务逻辑
方法一在效率上貌似有优势,但写 resultMap 和语句真是不开心方法二对程序员比较友好,但效率不如方法一,而且 service 层会比较臃肿
不知道大家的项目中都是如何使用的
个人比较喜欢使用第二种.因为目前所做的项目数据库表经常需要改动,加字段,而且我本人也是用mybatis generatro自动生成的,可能会覆盖掉。有没有什么好的建议?
1 回答
MMTTMM
TA贡献1869条经验 获得超4个赞
LZ的问题,我也思考过,可能是LZ没遇到过更复杂的业务逻辑,查询7,8张表的关联数据,这样的话,效率就太低了,
还有一种情况是,方法二的的处理明显的弊端是还要需要自己填充POJO数据,假如POJO的数据结构比较复杂,以后你维护起来自己都蒙蔽,resultMap 多做几遍就好了,结构很清晰,功能很强大,维护起来也方便。
无论是维护,还是查询效率,都是需要考虑的,程序员应该辛苦自己,让自己的程序变的更好
添加回答
举报
0/150
提交
取消