Spring Boot中REST Controller用Service接口是否符合依赖倒置原则？

问题背景 #

我正在学习Java中的依赖倒置原则（DIP），其定义为：

• 高层模块不应依赖低层模块，二者都应依赖抽象；
• 抽象不应依赖细节，细节应依赖抽象。

我有一段Spring Boot REST API的实现代码，想确认这段代码是符合依赖倒置原则，还是仅体现了依赖注入设计模式？

代码片段 #

Rest Controller代码

@RestController
@RequestMapping("/api")
public class EmployeeRestController {
    private EmployeeService employeeService;
    
    public EmployeeRestController(EmployeeService employeeService) {
        this.employeeService = employeeService;
    }

    @GetMapping("/employees")
    public List<Employee> findAll() {
        return employeeService.findAll();
    }
...
}

Service Interface代码

public interface EmployeeService {
    public List<Employee> findAll();
    
    public Employee findById(int theId);
    
...
}

Service Implementation代码

@Service
public class EmployeeServiceImpl implements EmployeeService {
    private EmployeeDAO employeeDAO;

    @Autowired
    public EmployeeServiceImpl(EmployeeDAO employeeDAO) {
        this.employeeDAO = employeeDAO;
    }

    @Override
    @Transactional
    public List<Employee> findAll() {
        return employeeDAO.findAll();
    }
    ...
}

Entity代码

@Entity
@Table(name="employee")
public class Employee {
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    private int id;
    
    @Column(name="first_name")
    private String firstName;
    ...
}

我的疑问 #

1. 我认为EmployeeRestController作为高层模块依赖EmployeeService抽象，EmployeeServiceImpl作为低层模块实现该抽象，这是否正确？
2. 依赖倒置与依赖注入在此示例中的区别是什么？我认为在控制器中声明private EmployeeService employeeService;是依赖倒置，若直接声明EmployeeServiceImpl则不满足；构造方法注入实现类是依赖注入，这个理解对吗？
3. 但Service接口中使用了实体类Employee，这是否属于抽象依赖细节，违反了依赖倒置原则的第二点？

解答 #

1. 高层/低层模块与抽象的依赖判断 #

没错，你的判断完全正确：

• EmployeeRestController属于高层模块（负责处理HTTP请求、对外暴露API，是业务流程的入口），它只依赖EmployeeService这个抽象接口，完全没有和具体实现EmployeeServiceImpl耦合；
• EmployeeServiceImpl是低层模块（负责业务逻辑的具体落地），它实现了EmployeeService抽象，同时依赖EmployeeDAO抽象（假设EmployeeDAO也是接口），完全契合DIP的第一条规则。

2. 依赖倒置与依赖注入的区别 #

你的理解方向没问题，再给你理清楚两者的本质：

• 依赖倒置（DIP）是设计原则：它是一种架构设计思想，核心是反转依赖方向——让高层模块不直接依赖低层的具体实现，而是都依赖抽象。比如控制器里声明EmployeeService而非EmployeeServiceImpl，就是遵循DIP的设计选择。
• 依赖注入（DI）是实现手段：它是具体的技术实现方式，用来把依赖的对象（比如EmployeeServiceImpl的实例）自动注入到需要它的类（比如EmployeeRestController）中，避免类自己去new依赖对象。你用的构造方法注入，就是DI的一种常见形式，它帮我们把DIP的设计思想落地。

一句话总结：DIP告诉你应该怎么设计依赖，DI告诉你怎么实现这种依赖。

3. Service接口使用Employee实体是否违反DIP？ #

这完全不违反DIP，原因在于：
DIP里说的“抽象不应依赖细节”，指的是抽象不能依赖可变的具体实现细节（比如某个特定的数据库操作类、某个第三方SDK的具体类）。而Employee是你的业务领域实体，它是业务模型的核心，属于稳定的业务抽象，并非“可变的细节”。

EmployeeService作为业务服务接口，本身就是围绕业务实体提供操作的，依赖Employee是它的职责所在，完全合理。只有当你的接口依赖的是某个具体的实现类（比如直接用JdbcEmployeeDAO而不是EmployeeDAO接口），那才是抽象依赖了可变细节，违反DIP。

内容的提问来源于stack exchange，提问作者elvis