我的服务文件中有以下方法：
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
我应该从我的服务返回什么类型？不应该是模型本身（我目前正在尝试返回）？
谢谢
【问题讨论】：
标签： java mongodb spring-boot spring-mongodb
您应该返回的类型在错误消息中。 findById() 返回一个Optional<MappingModel>，因此您可以将服务的返回类型更改为Optional<MappingModel>，也可以在服务中处理 Optional。
https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
编辑以向提问者提供有关 Optionals 的更多信息：
作为一名程序员，您可能已经面对可怕的 NullPointerException 数千次了。 Java 的一个大问题是，当您查看一个参数时，很难判断它是否可以为 null 或者它是否保证存在，因此通常最终会发生的是您的整个代码库都充满了 null 检查（这对于嵌套对象尤其糟糕）。
Optionals 是一种明确表示的方式，这个对象有可能是空的，你需要以某种方式考虑到这一点。这似乎是一件小事，但它实际上非常强大，原因有很多。
如果您在代码库中对 Optionals 的使用保持一致，那么您基本上可以消除可怕的空检查。如果您总是在某些内容可能为 null 时使用可选项，那么您是在暗示所有不是可选项的内容都不为 null，因此您获得的任何空指针都是代码中逻辑错误的结果（您知道需要修复）。
选项与流 API 配合得非常好。这是一个太大的话题，无法在这里讨论，但基本上，许多程序流程都非常简单。如果我们有该项目，我们会尝试对其执行一系列操作，但如果没有，那么我们不会或抛出异常。试试看，你会更喜欢 Optionals 的。我认为它会带来真正可读的代码。
许多软件包都支持 Optionals，因此它们可能会为您处理它们。例如，如果这个对象存在，那么我们将把它作为 JSON 响应的一部分返回。否则，我们将忽略它。
从用例的角度，想想使用像列表这样的集合是什么感觉。我们通常期望 List 永远不会为空，只是空的，所以使用它们感觉很好。 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");
}
【讨论】：