Question

我是初学Mvc的新手，在很多教程中，我发现有一个像这样的Dao界面

public interface StudentDAO {
    public List<Student> getStudents();
    public void addEntry(Student student);
    public void updateEntry(Student student);
    public void deleteEntry(Student student);
    public Student getStudentById(int id);
}

以及此类服务

public interface StudentService {
    public List<Student> getStudents();
    public void addEntry(Student student);
    public void updateEntry(Student student);
    public void deleteEntry(Student student);
    public Student getStudentById(int id);
}

这些接口都有实现。

我的问题是为什么我们需要接口而不是直接实现类？

Answer 1

也许最简单的具体例子就是测试。

使用DAO接口，您可以测试应用程序的逻辑，而无需运行可从运行测试的计算机访问的数据库，只需在测试期间将DAO实现交换为虚拟实现。然后，该虚拟实现可以为测试运行之间没有变化的测试提供一致的数据，不能在DB中意外覆盖，在Git / SVN /等等中进行版本化。

一般来说，这是Program to an interface, not an implementation设计原则的一部分。

根据我的经验，即使你永远不会有多个实现，这种界面与实现的分离也是一个好主意，因为它鼓励程序员更深入地思考契约类。

请注意，该原则并未得到普遍接受，例如here are some counter-arguments。

Answer 2

理论上，它创建了减少耦合的接口。换句话说，您创建的是作为通信合同的接口。有了这个，您可以为同一个合同提供更多的实施。示例：在PersonDao中，您可以使用hibernate实现，使用本机SQL实现。在你使用的地方，你只注入interace和CDI本身解决了实现，然后你可以轻松地改变实现，而不会影响它使用接口的地方。

在我的项目实践中，根据具体情况，不要创建接口，但我要强调，这取决于项目。示例：DAO在大多数情况下从未改变其实现，也就是说，我认为在这些情况下不需要创建接口直接实现具体类。

Jiri Tousek是一个使用接口的例子。但是在我的测试中，我总是使用完整的流程，包括数据库。

Answer 3

我很高兴看到有人质疑这种做法。

Spring Framework很久以前就介绍了为托管服务/ DAO bean定义接口的模式。我认为这种做法是由于他们用来创建动态代理的技术的限制而引入的。

当定义了Spring管理的bean时，框架会为底层实例创建一个代理，目的是使用AOP技术通过交叉功能对其进行装饰。显然，他们用于在早期版本的Spring Famework中实现这些代理的工具需要一个接口来创建代理。

此要求不再适用于最新版本的Spring Framework，您可以安全地处理这些无用的接口。

现在，由于像Mockito这样的模拟框架也能够模拟具体的类，因此易于测试的原因也不存在。此外，您可以使用@Primary批注在测试环境中使用自定义模拟替换实际实现。

由于这些原因，我会废弃内部服务和DAO类的接口，这些接口永远不会有多个共存的有效实现。

保留真正需要它们的设计模式的接口。

Answer 4

如果您正在进行项目，它包含一些数据库，因此您必须以这种方式在界面中定义函数，您可以很容易地看到它。

需要道和服务接口

4 个答案: