Question

我有Spring控制器，它使用构造函数注入来满足服务层依赖性。效果很好。现在，组织中有一些旧代码，它们会仔细检查依赖项是否有效。我认为这是一个反模式，因为它的代码与交叉关注问题有关，注入的客户不应该担心。

如果无法解决依赖关系，那么IoC容器（Spring）将引发相应的错误（UnSatisfiedLink或其他），使用这些服务的客户端应该不知道如何或者是否正确地注入了这些依赖关系..它应该假设所有依赖项都已初始化并准备就绪。这是首先使用IoC的本质。

例如我看到了这个：

  public MyController(MyService myService) {
     this.myService = myService;
  }

然后：

@PostConstruct
public void afterPropertiesSet() throws Exception {
 if(myService == null) {   // unecessary in my opinion
   throw new IllegalArgumentException("MyService is not set!");
 }
}

这些类型的“双重检查”是不必要的，导致交叉关注代码混乱，意见？

Answer 1

我不会考虑像这样的支票

if(myService == null) {
 //throw nice readable error
}

杂乱，我会删除作为代码审查的一部分。我将更多地看到的问题是“抛出异常”部分，您必须现在作为此方法的一部分介绍。因此，调用此方法的每个方法现在都需要实现try / catch或re-throw实现。

我宁愿推荐一个继承自RunTimeException的异常。

原因是这是一个异常，会出现严重的配置或设置错误。您不希望这种情况发生在任何类型的常规功能中。所以我不认为任何其他方法需要“通知”并且有一个特殊的try / catch块来表现不同。该应用程序应该基本上崩溃与异常。就在这时候。在全局服务级别上可能有一些捕获处理程序捕获这些异常，然后，例如回滚事务，转换SoapError中的异常等。但通常我不会考虑抛出和显式异常中的任何其他值，这需要其他调用方法来实现特殊的catch块。

在Spring

1 个答案: