一直不太明白
一般说dao层只做基础的增删改查
那service层做逻辑的话就会调用很多次基础的增删改查，增加了许多数据库查询次数
上次就因为这事被组长说了一顿
然后组长改的是在dao层把增删改查加上逻辑的限制条件，这样就可以只查很少次数的数据库
但这样dao和service就感觉很混乱啊？虽然确实这样service层的代码可读性还更高了，毕竟调dao层很多次代码也不好看
eg.先需要查表a的全部和表b的一个字段，我是写了个select * from a，再写了个select x from b，然后在service调用；组长是只写了一个select，用left join 连起来的，service就只调用一个select
所以到底该以什么标准？这是他们公司特色还是正常来说都是这么写的？
这么说吧.
只要某种效果,你可以通过一条sql完成,那你就应该在dao层写.
就这么简单的逻辑.
service是把你一条sql解决不了的问题,进行逻辑拼装.
比如你要查a.*,b.x,那么你完全可以通过join方式连接.
除非a表是一个数据库,b表是另一个微服务下的数据库.
这种情况,你可以分别获取.
简单来说,dao层写的是sql代码.多复杂都行.
如果你真的能一条sql搞定,那你没有service都行.
service就是用来处理一条sql解决不了的情况.确实有点混乱.
你要是mybatis的mapper接口 ，你还怎么写你的业务逻辑？
数据库操作就只管数据库操作，别整一大堆逻辑进去（必要的条件筛析可以有），这里写那里写，必然逻辑混乱；
而且你这种查询多次，你不会连表啊？
一般设计数据表合理的话，一个表对应一个业务对象，不需要join表，如果是业务key，可以用冗余的方式存在每个核心表里避免join。如果需要多个表的数据，可以另外在service用dto把多个领域对象包起来。不过各公司有自己习惯，和表设计代码风格都有关
你这确实需要多表查询，不过还是sql查出来数据，service层进行处理比较好，因为这样后期业务变动的话好维护。sql除了查数据非必要不要有太多逻辑。
这么说吧，dao层只是操作数据库的，service是进行数据处理的。
举个简单的例子。
用户登录，需要查看是否有这个用户？账号密码是否正确？
可以用一个sql搞定：select * from sys_user where name = '张三' and pwd = '123456'
这个就是dao层通过mapper来完成的。（当然一些简单的连表查询，或者条件查询，条件判断等，都可以用一条sql实现）
但是查询到的结果呢？我们需要对结果处理。
如果查到信息了，说明用户登录成功。那么接下来可能会有很多相关操作。比如记录用户的登录信息，用户信息缓存到redis，获取用户的相关权限等等，这些都是要在service中完成。如果没有查到信息，那么用户登录失败，需要返回msg，告诉用户登录失败。这些是无法用一个sql实现的。这就用到了service层。
不知道我说明白没？