Question

有些人覆盖了CrudRepository的方法findAll来返回Stream（java 8），但是我看到他们最终将Stream转换为List以便通过rest控制器发送它。他们为什么要使用Stream？在这里使用Stream有什么好处？如果他们想要过滤记录，我认为可以更好地过滤DataBase。

Answer 1

Spring Data JPA已经支持这一点，看看here;因此，覆盖返回Stream的那些并不是真正的优势。如果你真的想要Stream以及它带来的一些潜在优势 - 使用Spring Data JPA提供的功能。

另一个不同的方面是JPA Spec 2.2这可能是某些查询的默认返回类型。 JPA接口Query和TypedQuery将获得一个名为getResultStream()的新方法。

因此，Spring Data将使用特定提供程序的特定技术（如Hibernate或EclipseLink）来传输结果。

默认情况下，getResultStream只是list.stream实施，但Hibernate已经覆盖了ScrollableResult。如果您需要处理非常大的结果集，这会更有效。

Answer 2

人们想要使用Stream的原因可能有多种原因。

如果您在数据库中进行任何您不想或不想做的处理，Stream可能更适合使用。
它如此时髦，功能强大。几乎每个人似乎都在尝试正确的功能组合。所以完全有可能甚至可能使用Stream没有任何好处。但是，它的成本也不高。

Answer 3

将其提供为Stream使存储库使用者可以选择如何收集数据。另外，它允许在流上进行操作的链接/管道连接，例如映射到DTO，扩充数据和过滤。如果您唯一要做的就是将其收集到列表中并作为响应发送，那么就没有任何好处。

但是以Thing存储库返回List<Thing> findAllThings() n个中的Things个例子为例，因为大多数情况下它只是通过API作为列表发送。但是，随后有人在应用程序中构建了一个服务，该服务仅需要过滤应用程序中另一组Things m中存在的Things。我们将不得不像这样的集合重新创建列表过滤

List<Thing> acceptedThings = repo.findAllThings()
                                 .stream()
                                 .map(t->set.contains(t))
                                 .collect(toList());

因此，我们不得不迭代原始列表并重建一个新列表。如果此列表上还有其他操作，您会发现它可能不是最佳选择。

如果来自存储库的响应为Stream<Thing>，那么我们可以链接过滤器操作并传递到Stream上以进行进一步处理。

Stream<Thing> acceptedThings = repo.findAllThings()
                                   .map(t->set.contains(t));

只有在某些东西消耗完流的最后，才执行与每个项目相关的所有操作。这样效率更高，因为每个元素最多只需要访问一次，并且不需要创建任何中间集合。

鉴于Spring现在支持在控制器中像@ResponseBody一样返回Streams，那就更好了。

流和弹簧数据的优点

3 个答案: