方法一
Dao 层有一对多、一对一关联
Service 层写业务逻辑
方法二
Dao 层不写一对多、一对一关联，只提供基本的增删查改
Service 层完成关联查询等以及写业务逻辑
方法一在效率上貌似有优势，但写 resultMap 和语句真是不开心
方法二对程序员比较友好，但效率不如方法一，而且 service 层会比较臃肿
不知道大家的项目中都是如何使用的
个人比较喜欢使用第二种.因为目前所做的项目数据库表经常需要改动，加字段，而且我本人也是用mybatis generatro自动生成的，可能会覆盖掉。有没有什么好的建议?
将DAO操作写成dubbo服务来单独开发调用 O(∩_∩)O
mybatis很强大的，我个人都是用第一种。
一对多mybatis很强大的，我个人都是用第一种。能一次查询出来的东西并不想查询两次
比如要查询菜单数据，菜单数据有一级二级，那么按照方法二，查询一级菜单后再去循环查询二级菜单，查询消耗很大。
就算是查询两次的做法，那么service循环的处理逻辑也很烦人的感觉。而且还有关联三个表以上的一对多复杂查询，方法一的简单查询就会要了命。
查询一条两条数据用第二种，查询CMS系统列表分页数据还是用第一种方便的多。况且用熟了，也就是拷贝复制的事情。两种情况结合使用吧。
https://www.cnblogs.com/yaobolove/p/5444046.html
一种是：使用嵌套结果映射来处理重复的联合结果的子集
另一种呢是：通过执行另外一个SQL映射语句来返回预期的复杂类型