SpringBoot应用程序中的每个@Service类是否应该实现一个接口

Question

嗨，Spring/SpringBoot粉丝/专家，

希望你做得很好。我已经为这个问题纠结了一段时间了，我想我应该向春天/春天的专家请教他们对这个问题的看法和经验。它是关于接口的，因为它与它在springboot中的使用有关。

首先，让我这样说；从Java或软件工程的角度来看，我理解并非常清楚接口的使用或用途，它们是契约。

因此，从作为框架/库的角度来看，它在框架源代码中是有意义的。

现在，从springboot作为一个应用程序，我看到每个服务类(@ service )都有一个相应的接口：

public interface MyService {} 
public class MyServiceImpl implement MyService {}

99.99%的情况下，这些接口永远不会被其他任何东西实现。为什么在springboot中这会成为一件很流行的事情，因为每个服务类都有相应的接口，尽管其他任何接口都不会实现这些接口？

在我看来，它似乎创造了更多的复杂性和代码来维护，并没有明显的好处。请注意，我严格地指的是@Service类接口。

这样做是很好的做法吗？这里有什么东西我遗漏了吗。请问您对此有何经验和想法？

提前谢谢你！

Answer 1

这种模式确实在相当多的教程和在线资源中被使用过，但我认为它已经相当过时了。在XML时代，您没有配置类这样的东西，因此配置bean的主要方法是XML条目，为协作者配备公共设置器。由于您不希望在API中公开这一点，所以有一个声明公共API的接口以及处理它的实现是有意义的。

随着现代春天的到来，这种世界观已经完全过时了，当然我们也没有强烈的愿望去追求这样一个范例。构造函数注入现在已成为常态，因此接口与其唯一实现之间的分离并不是非常有用的。

人们可能会说，他们不希望任何Spring注释出现在公共API上，因此这仍然是一种用途。也就是说，如果使用构造注入和显式bean注册，则不需要任何依赖注入注释。如果您对此有强烈的感觉，并使用其他方面，例如事务或缓存，那么如果您想要将这些注释隐藏在公共API中，就必须创建一个接口。

Answer 2

在春季，@Service通常负责特定的业务逻辑，而业务代码通常包含许多更改。因此，它通常是使用接口实现的。我不太明白为什么您的业务代码总是空的。