我开始在我的项目中使用构造函数注入,因为Spring声明了字段注入不被弃用。实际上,代码感觉更漂亮,更严格,我很好。 但是我遇到了一种模式,对我来说似乎有些奇怪和冗长:
我有一个抽象的服务bean类(带有@Service
注释),它有2个依赖项,直接在构造函数中注入:
@Autowired
public AbstractService(DependencyA depA, DependencyB depB) {
this.depA = depA;
this.depB = depB;
}
然后我有多个服务bean类(仍然带有@Service
注释)扩展抽象类。
而且我不知道是否还有另一种方法,但这是我发现在每个子类构造函数中有点冗长和重复必须为父项注入依赖项的地方:
@Service
public class ServiceA extends AbstractService {
private final DepC depC;
@Autowired
public ServiceA(DepA depA, DepB depB, DepC depC) {
super(depA, depB);
this.depC = depC;
}
}
我只是想知道这是否正确,你对此有何看法?
答案 0 :(得分:3)
@Autowired
上的AbstractService
没有做任何事情。将其更改为:
@Service
public class ServiceA extends AbstractService {
private final DepC depC;
@Autowired
public ServiceA(DepA depA, DepB depB, DepC depC) {
super(depA, depB);
this.depC = depC;
}
}
...
public AbstractService(DependencyA depA, DependencyB depB) {
this.depA = depA;
this.depB = depB;
}
我对此设置没问题。
对我来说,使用构造函数注入的主要好处是告知开发人员什么是外部依赖项。我发现在编写单元测试时它很有用。在编写模拟时,您只需知道需要嘲笑的内容。
其他好处是为了突出显示一个Class有太多依赖项时,它会提示重构可能是有序的。
替代将使用setter注入(同时保持信息方面),但我已经成长为享受构造函数注入。
答案 1 :(得分:1)
我的回答是关注你问题中的“冗长和重复”部分;我让其他人决定如何“正确”使用注释。
即使使用Spring及其DI框架,我们仍然在讨论 Java 源代码!
在Java中,如果您的基类仅提供了一个带有A和B的构造函数;那么当然你的子类必须进行超级调用(A a,B b);当然,那些价值观a和b必须来自某个地方!
因此,您所谓的“详细和重复”是使用Java的直接后果。
换句话说:没有办法避免这一部分!