是否每个 Play 框架 Web 请求都使用新的依赖注入控制器实例来处理，但是静态控制器方法呢? [英] Is each Play framework web request handled with a new dependency injected controller instance, but then what about static controller methods?

问题描述

我的问题是关于 Java 的 Play 框架中控制器的生命周期，控制器是有状态实例还是具有静态方法的无状态，以及如何在控制器代码中使用依赖注入.

My questions are about the lifecycle of controllers in the Play framework for Java, if the controllers are stateful instances or stateless with static methods, and how to use dependency injection in the controller code.

每个 Web 请求是否由 Play 控制器类的新实例处理，即控制器是否可以将状态存储在注入控制器构造函数的服务等字段中?(文档在哪里解释?)

Is each web request handled by a new instance of a Play controller class, i.e. can a controller store state in fields such as services injected into the controller constructor? (where in the documentation is it explained?)

对于控制器是有状态实例还是具有静态方法的无状态控制器，Play 框架与早期版本相比是否发生了变化(如果有，是什么版本?)?

Has the Play framework changed since earlier versions (and if so, at what version?) regarding if controllers are stateful instances or stateless controllers with static methods?

在哪里可以看到使用有状态控制器时框架如何将服务注入控制器实例的代码示例以及如何将服务注入静态控制器方法的示例?

Where can you see code examples about how the framework injects services into a controller instance when stateful controller is used and example of how to inject services into a static controller method?

关于后者，即注入静态方法，我想它要么必须是框架将添加的方法的参数，要么如果不可能，您可能不得不在方法中使用服务定位器例如实例化一个 Guice 模块类，然后在静态控制器方法中使用injector.getInstance".

Regarding the latter, i.e. injection into a static method I suppose that would either have to be a parameter to the method which the frameworks will add, or if not possible you maybe instead will have to use a service locator from within the method e.g. instantiate a Guice module class and then use "injector.getInstance" from within the static controller method.

在下一页的依赖注入控制器"部分中涉及到这个主题:

This subject is touched in the section "Dependency injecting controllers" at the following page:

https://www.playframework.com/documentation/2.4.x/JavaDependencyInjection

但是，它没有用代码显示如何将服务实际注入控制器实例(但可能与其他组件"相同，即使用 @Inject 注释)，当然它目前没有显示如何将 DI 与静态控制器方法.

However, it does not show with code how to actually inject services into a controller instance (but probably the same way as other "components" i.e. with @Inject annotation) and certainly it does not currently show how to use DI with a static controller method.

我对这些事情感到困惑，因为我没有找到清楚说明我的问题的文档，而且我还在一本 Play 书中(从 2013 年开始)读到控制器方法应该被编程为无状态并且控制器方法应该是静态的.

I am confused about these things because I have not found documentation being clear about my questions, and I have also read in a Play book (from 2013) that the controller methods should be programmed as stateless and the controller methods should be static.

但是，当现在使用激活器生成具有最新 Play 版本 (2.4.6) 的 Java Play 应用程序时，我可以看到生成的控制器方法 (Application.index) 不是静态的.此外，在以下文档页面中，控制器方法不是静态的:https://www.playframework.com/documentation/2.4.x/JavaActions

However, when now using activator for generating a Play application for Java with the latest Play version (2.4.6) I can see that the generated Controller method (Application.index) is NOT static. Also, at the following documentation page, the controller method is NOT static: https://www.playframework.com/documentation/2.4.x/JavaActions

这很令人困惑，因为了解每个请求是否由 Controller 实例处理(即是否可以使用状态)是非常重要的，我认为这应该在关于 Controller/Actions 的页面上更好地记录比没有解释它的当前文档(上面的链接页面).

This is confusing, and since it is VERY fundamental to understand whether or not each request is handled by a Controller instance or not (i.e. if state can be used) I think this should be better documented at the page about Controller/Actions than the current documentation (the above linked page) which is not explaining it.

关于依赖注入的文档在依赖注入控制器"部分提到了静态路由生成器"，涉及静态和非静态方法的主题，但我认为应该更好地解释它，包括代码示例.

The documentation about dependency injection touches the subject about static and non-static methods at the section "Dependency injecting controllers" mentioning "static routes generator" but I think it should be better explained including code examples.

如果 Play 团队中的某个人正在阅读此问题，请在上述链接页面中添加一些信息，例如，请务必提及(如果我的理解是正确的)在 Play 的早期版本中，控制器方法是静态的，并且那些版本你不应该在字段中存储状态，但是在以后的版本中(从版本 x 开始?)每个请求都由控制器的一个实例处理，因此可以使用状态(例如框架注入的构造函数参数).

If someone in the Play team is reading this question, then please add some information to the above linked pages, for example please do mention (if my understanding is correct) that in previous versions of Play the controller methods were static and for those versions you should never store state in fields, but in later versions (beginning from version x?) each request is handled by an instance of a controller and can therefore use state (e.g. constructor parameters injected by the framework).

还请提供有关与静态控制器方法一起使用的注入以及每个请求一个实例注入到有状态控制器实例的代码示例.

Please also provide code examples about injection used with static controller methods and injection into stateful controller instances with one instance per request.

依赖注入页面中的组件生命周期"部分只提到了组件"，但我认为它也应该明确说明控制器生命周期及其注入，因为与所有开发人员进行清晰沟通是一项基础和重要的知识避免由于对是否有状态的误解而导致的错误.

The section "Component lifecycle" in the dependency injection page only mentions "components" but I think it should also be explicit about the controller lifecycle and its injection, since it is such a fundamental and important knowledge to communicate clearly to all developers to avoid bugs caused by misunderstandings about being stateful or not.

推荐答案

每个 Web 请求是否由 Play 控制器类的新实例处理，即控制器是否可以将状态存储在注入控制器构造函数的服务等字段中?(文档在哪里解释?)

Is each web request handled by a new instance of a Play controller class, i.e. can a controller store state in fields such as services injected into the controller constructor? (where in the documentation is it explained?)

据我所知，控制器默认是单例对象.这没有明确记录，但暗示控制器实例被重用.请参阅 Playframework 2.4 迁移指南:

As far as I can tell, controllers are by default singleton objects. This is not clearly documented, but it is implied that controller instances are reused. See the migration guide for Playframework 2.4:

注入的路由生成器也支持路由上的@运算符，但它的含义略有不同(因为所有内容都是注入的)，如果您在控制器前面加上@，而不是直接注入该控制器，则为 JSR 330 Provider该控制器将被注入.例如，这可用于消除循环依赖问题，或者如果您希望每个请求都实例化一个新操作.

The injected routes generator also supports the @ operator on routes, but it has a slightly different meaning (since everything is injected), if you prefix a controller with @, instead of that controller being directly injected, a JSR 330 Provider for that controller will be injected. This can be used, for example, to eliminate circular dependency issues, or if you want a new action instantiated per request.

另外，请查看 James Roper 提出的这个推荐(播放核心提交者)关于控制器是否是单例的:

Also, check this commend made by James Roper (Play core committer) about if controllers are singleton or not:

并非如此 - 如果使用 Guice，每次将控制器注入某些东西时，默认情况下都会创建一个新实例.也就是说，路由器是单例的，因此通过关联，它调用的控制器是单例的.但是，如果您在其他地方注入控制器，它将为该组件重新实例化.

Not really - if using Guice, each time the controller is injected into something, a new instance will be created by default. That said, the router is a singleton, and so by association, the controllers it invokes are singleton. But if you inject a controller somewhere else, it will be instantiated newly for that component.

这表明默认情况下是在响应请求时重用控制器实例，如果您希望每个请求都有一个新操作，则需要使用迁移指南中描述的语法.但是...由于我更倾向于证明和尝试事物而不是仅仅相信，因此我创建了一个简单的控制器来检查该陈述:

This suggests that the default is to reuse controller instances when responding to requests and, if you want a new action per request, you need to use the syntax described in the migration guide. But... since I'm more inclined to prove and try things instead of just believe, I've created a simple controller to check that statement:

package controllers

import play.api._
import play.api.mvc._

class Application extends Controller {

  def index = Action {
    println(this)
    Ok(views.html.index("Your new application is ready."))
  }

}

对该操作执行多个请求会为所有发出的请求打印相同的对象identity.但是，如果我在路由上使用 @ 运算符，我会开始为每个请求获取不同的 identities.所以，是的，控制器默认是(某种)单例.

Doing multiple requests to this action prints the same object identity for all the requests made. But, if I use the @ operator on my routes, I start to get different identities for each request. So, yes, controllers are (kind of) singletons by default.

对于控制器是有状态实例还是具有静态方法的无状态控制器，Play 框架与早期版本相比是否发生了变化(如果有，是什么版本?)?

Has the Play framework changed since earlier versions (and if so, at what version?) regarding if controllers are stateful instances or stateless controllers with static methods?

默认情况下，Play 一直提倡无状态控制器，您可以在项目主页看到:

By default, Play had always advocated stateless controllers, as you can see at the project homepage:

Play 基于轻量级、无状态、网络友好的架构.

Play is based on a lightweight, stateless, web-friendly architecture.

这并没有改变.因此，您不应使用控制器的字段/属性来保存随时间/请求而变化的数据.相反，只需使用控制器的字段/属性来保持对同样无状态的其他组件/服务的引用.

That had not changed. So, you should not use controllers' fields/properties to keep data that changes over time/requests. Instead, just use controllers' fields/properties to keep a reference to other components/services that are also stateless.

在哪里可以看到使用有状态控制器时框架如何将服务注入控制器实例的代码示例以及如何将服务注入静态控制器方法的示例?

Where can you see code examples about how the framework injects services into a controller instance when stateful controller is used and example of how to inject services into a static controller method?

关于代码示例，Lightbend 模板存储库 是不错的选择.以下是一些在控制器级别使用依赖注入的示例:

Regarding code examples, Lightbend templates repository is the place to go. Here are some examples that use dependency injection at the controllers level:

1. https://github.com/adrianhurt/play-api-rest-seed
2. https://github.com/knoldus/playing-reactive-mongo
3. https://github.com/KyleU/boilerplay

不支持使用静态方法的依赖注入，这就是 Playframework Stills 提供 旧 apis 与静态方法一起使用.这里的经验法则是:在 DI 和静态方法之间进行选择.尝试同时使用这两种方法只会给您的应用程序带来复杂性.

Dependency Injection with static methods is not supported, and that is why Playframework stills offers old apis to use with static methods. The rule of thumb here is: choose between DI and static methods. Trying to use both will just bring complexity to your application.

这篇关于是否每个 Play 框架 Web 请求都使用新的依赖注入控制器实例来处理，但是静态控制器方法呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！