performance - 为什么Grails推荐使用 Action 作为方法的 Controller 的单例作用域？

Question

我知道Grails的早期版本使用了 Controller 的原型(prototype)作用域，因为当时所有 Action 都是封闭的。

我知道当前版本的文档建议使用方法作为操作的 Controller 的单例作用域 Controller 。

从下面的帖子中，似乎更希望或推荐使用方法和单例作用域，但尚不清楚原因。

ttp://grails.1312388.n4.nabble.com/Default-scope-for-controllers-doc-td4657986.html

我们有一个大型项目，该项目使用原型(prototype)作用域 Controller 将 Action 作为方法。更改为建议的 Controller 范围会涉及风险和重新测试，以及从现有 Controller 中删除任何非单点友好状态。

我想知道，为什么Grails建议将单例作用域用作方法作为 Action Controller ？仅仅是因为这与Spring MVC更为常见且相似，并且避免了混淆，或者是否有提高性能的机会，还是什么？ 如果切换到单例 Controller ，我将获得什么？ 如果我不进行切换，费用是多少？

Answer 1

我与Rails的合作并不多，但是(至少在我玩过的版本中，现在可能有所不同) Controller 是模型，其中包含要由 View 呈现的数据。在请求处理期间，您将值存储在 Controller 实例字段中，然后再进行处理以查看渲染器。因此，为每个请求创建一个新的 Controller 实例是有意义的，因此它们是不同的。

Grails受到Rails的启发，并使用了它的几种约定，最著名的是over over configuration。但是，虽然没有充分的文档记录，但我也怀疑很多人使用了它，但是还增加了使用 Controller 作为模型的功能。

使用GSP呈现响应(与转发或重定向，或直接在 Controller 中呈现，例如render foo as JSON相反)时， Controller Action 的典型工作方式是从 Action 中返回一个或多个键/值对，并且通常省略return关键字，因为它在Groovy中是可选的:

class MyController {
   def someAction() {
      def theUser = ...
      def theOtherObject = ...
      [user: theUser, other: theOtherObject]
   }
}

在这里，模型图有两个条目，一个由 user键入键，另一个由 other键入键，这些将成为GSP中用于访问数据的变量名。

但是大多数人不知道的是，您也可以这样做:

class MyController {

   def user
   def other

   def someAction() {
      user = ...
      other = ...
   }
}

在这种情况下，不会从操作返回模型映射，因此Grails将从 Controller 类的所有属性中填充模型，并且在这种情况下，由于第二种方法中的变量名是与第一个中的 map 键相同。

使 Controller 成为单例的选项是在2.0中添加的(在重命名为2.0之前，在技术上为1.4，请参见 this JIRA issue)，并且除了保留对闭包的支持之外，我们还添加了对方法作为操作的支持。最初的假设是使用闭包将启用一些有趣的功能，但从未实现。使用方法更为自然，因为您可以在子类中覆盖它们，这与仅属于类作用域的闭包不同。

作为2.0返工的一部分，我们删除了受Rails启发的功能，并假设该功能基本上没有记录，因此对使用该功能的少数奇特应用程序的影响不大。我不记得有人提示失去该功能。

尽管 Controller 类通常很容易被垃圾回收，并且每个请求创建一个实例影响不大，但是很少需要 Controller 中每个请求的状态，因此单例通常更有意义。保留了默认的原型(prototype)范围是为了向后兼容，但是可以通过Config.groovy属性轻松更改默认原型(prototype)(由 create-app脚本生成的文件可以做到这一点)。

尽管每个请求的确获得了新的请求和响应，并且如果使用了 session ，则每个用户将拥有自己的 session ，但这不是 Controller 的实例字段。它们看起来像是因为我们可以在 Action 内部访问 request， response， session， params等，但实际上它们是 getRequest()， getResponse()， getSession()和 getParams()方法的属性访问形式，这些形式在编译期间已混合到所有 Controller 中通过AST转换。这些方法不是通过类字段而是通过ThreadLocals访问它们的对象，因此存在每个请求的状态，但未存储在 Controller 实例中。

我不记得在基准测试中使用方法和闭包进行比较的方式是否很多，但是Lari Hotari可能做了一些。如果存在差异，则可能并不重要。您可以通过仅转换一个或几个 Controller 并在测试之前和之后进行操作，来在自己的应用程序中对其进行测试。如果这两种方法之间的性能，扩展性和内存差异不大，则可以放心使用原型(prototype)分数和/或闭包。如果存在差异，并且您的 Controller 中没有实例字段，那么转换为单例和方法可能是值得的。

如果确实有实例字段，则它们可能可以转换为请求属性- request.foo = 42是 request.setAttribute('foo', 42)的元类快捷方式，因此您可以安全地在其中存储每个请求的数据。