MVC模式关于Service分层的问题咨询

Question

大佬们好，我是小白，开发过程中一直有个疑问，MVC是我们目前流行用的JAVA后端开发模式。

目前我们公司项目中按照controller包、service包、dao包这种结构组织代码，业务逻辑实现代码主要放在Service中，但是有些透传去数据库中查询的代码也在Service中。

我的疑问就是，业务逻辑代码再Service中是没问题的，没有业务逻辑的、只是透传到Dao层去数据库查询的方法代码是不是应该单独起一个包存放。

PS:目前项目团队人少，工程规模也不大，所以目前的结构模式是合理的、不需要过度拆分的。只是在结构模式的功能分层上想咨询一下我的想法是否合理。

希望大佬们或者由经验的前辈们给一下指导。

Answer 1

和楼主一样，这个问题当初也困扰我了很长一段时间。

在实际的项目中，由于JPA无法满足综合查询的实际要求，所以我们会把一些本该由dao层负责的方法迁移到service中。这当然是不合理的，DDD开发风格决定了我们应该把与数据库打交道的方法写到dao中。

但是Spring Boot的官方guide并没有解决上述问题相关的知识，查询到的一些第三方资料也大多在讲：如何在service构造Specification。所以说不是我们不想把与数据库打交道的全部放到dao层中，而是没有掌握如何在dao层中来实现综合查询。

完全可以将综合查询放到dao层，具体的使用方法请参考：
1 代码萌动：Spring Data JPA 创建、组合自定义仓库
2 看云：仓库层中抽离各查询条件后在service中快速组合

Answer 2

理论上来讲还有一个MVC中的“M”，即model，在可以是mybatis之类的ORM层，一般数据库的操作都放到ORM中，而实际上调用ORM的地方就是service层。所以在service里面进行数据库查询是没问题的。

虽然说service中放的是业务逻辑，但是数据库的查询实际上是调用Model层的接口，并不是直接操作数据库。就像controller中会调用service的接口一样。

Answer 3

“没有业务逻辑的、只是透传到Dao层去数据库查询的方法代码”是什么样的代码呢？
一些这方面的通用逻辑是可以单独抽一层出来的，参考阿里的设计规范

Answer 4

你说的是那些简单的单表的CURD吧? 可以抽取写成通用的CURD接口 , 你自己的dao接口继承就拥有可以使用这些接口的权限了, 类似:

public interface BaseMapper<T> {
    
    int deleteByPrimaryKey(Object id);

    int insert(T record);

    int insertSelective(T record);

    T selectByPrimaryKey(Object id);

    int updateByPrimaryKeySelective(T record);

    int updateByPrimaryKey(T record);
    
}

自己的接口继承这个接口不用写这些方法即可:

public interface xxxxxMapper extends BaseMapper<PartnerAccountBank>