应该何时在Play框架中返回Promise而不是实际结果？

Question

我对Play Framework比较陌生.我正在处理的当前项目有大量Promise的服务层组件返回到控制器.我想知道这是不是最好的做法.在我看来,使用Promises确实使源头变得混乱.而且我必须过于频繁地使用final修饰符,只是为了让Function我需要为这些Promises 创建匿名的局部变量,参数和类成员.它甚至影响我创建单元测试用例的方式.诚实地说它很丑陋,而且代码行数太多而不是必要的.我甚至不确定我们是否正确行事,我觉得我们过度使用了Promises.

我顺便使用Java.

所以,当我应该使用Promise,当我应该返回Promise,我应该何时不使用Promise？我们所有的服务和接口都应该返回Promise吗？有没有更好的方法呢？请用简单的英语.

Answer 1

当您进行昂贵且相对耗时的操作时,将使用Promise.例如,如果您在数据库上进行密集查询,则不希望在收集所有记录时让前端用户等待.

在这种情况下,您将返回Promise而不是Result.由于它等待密集计算的响应,这将阻止前端挂起.一旦计算完成,它将收到实际结果.

Promise在一个单独的线程中运行,因此只在必要时才使用它们.在大多数情况下,您只需要使用结果.

Play中有一个很好的页面!所有关于异步HTTP编程的框架文档:

Promise最终将使用Result类型的值进行兑换.通过使用Promise而不是普通的Result,我们可以快速返回我们的操作而不会阻塞任何内容.一旦兑换承诺,Play将立即提供结果.

如果您需要流式传输数据,我还会看一下EventSource(用于服务器发送的事件)或WebSockets.我还建议查看最新版本的Play(2.3)并让Java 8利用Lambda Expressions,这将减少代码的冗长.您可以在此处查看有关Typesafe的一些示例.

哦,看起来你似乎过度使用了Promises.如果您正在进行时间和计算资源昂贵的计算,则只需要它们.同样,如果您的代码由于匿名内部类和函数而看起来不可读,我强烈建议升级到Java 8并使用Lambda Expressions.

Answer 2

虽然它是一个旧线程，但保留Play最新文档的响应以澄清评论中的后续问题，即如何在客户端处理 Promise 响应。使用 Play，客户端将保持阻塞等待响应，而如果控制器返回 Promise，则服务器不会因 I/O 被阻塞。最终，Promise 将被赎回并返回 I/O 的结果。

...我们能够快速从我们的行动中返回而不会阻止任何事情。兑现承诺后，Play 将立即提供结果。

Web 客户端在等待响应时会被阻塞，但在服务器上不会被阻塞，并且可以使用服务器资源为其他客户端提供服务。