Java Spring Boot-MongoDB findById编译错误

如何解决Java Spring Boot-MongoDB findById编译错误

我的服务文件中包含以下方法：

public MappingModel getById(String id) {
        return repository.findById(id);
    }

这是我的存储库：

public interface MappingRepository extends MongoRepository<MappingModel,String> {

    List<MappingModel> findByProject(String project);

}

在编译时出现以下错误：

不兼容的类型： java.util.Optional 不能为 转换为com.xxx.xxx.xxx.model.MappingModel

我应该从服务中退回什么类型？不应该是模型本身（我目前正在尝试返回什么）？

谢谢

解决方法

错误消息中应该返回的类型。 findById（）返回一个Optional<MappingModel>，因此您可以将服务的返回类型更改为Optional<MappingModel>，也可以处理该服务中的Optional。

https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html

编辑以向提问者提供有关可选的更多信息：

作为一名程序员，您可能已经遇到过可怕的NullPointerException数千次了。 Java的一个大问题是，当您查看参数时，真的很难分辨它是否可以为null或是否保证存在该参数，因此通常最终会发生的是整个代码库中都填充了null检查（这对于嵌套对象尤其不利。）

可选是一种明确的说法，该对象有可能为null，您需要以某种方式加以说明。这似乎是一件小事，但实际上由于某些原因它非常强大。

1. 如果您与代码库中对Optionals的使用一致，那么您基本上可以消除可怕的null-check。如果在某些内容可能为null的情况下始终使用可选的内容，则表示所有非可选的内容都不为null，因此，您获得的任何nullpointer都是代码中逻辑错误的结果（您知道需要修复）。

2. 可选选项与流API的配合非常好。这是一个太大的话题，无法在这里讨论，但是基本上，许多程序流程都非常简单。如果有该项目，则尝试对其执行一系列操作，但如果没有，则不执行或抛出异常。尝试一下，这样做后，您会更欣赏Optionals。我认为这会导致代码真正可读。

3. 许多软件包都支持Optional，因此它们可能会为您处理。例如，如果存在此对象，那么我们将其作为JSON响应的一部分返回。否则，我们将忽略它。

从用例的角度，考虑使用像列表这样的集合的感觉。我们通常希望List永远不会为null，而只能为空，因此使用它们感觉很好。 Optionals有点像对此的扩展（并且许多流API方法都被重载以同时处理Collections和Optionals）。

,

当您使用MongoRepository的findById()时，它将为您提供Optional<>类型，这意味着数据可以存在于数据库中，也可以不存在于数据库中。所以像下面这样改变类型

 public Optional<MappingModel> getById(String id) {
        return repository.findById(id);
    }

在服务实现中使用此方法时，需要使用

public MappingModel getById(String id){
   if(repository.getById(id).isPresent())
   {
       MappingModel m= repository.getById(id).get();
       // then your usual logic
       return m;
   }
   throw new RuntimeException("Data not found");
}