表演 – 为什么玩！框架选择了Groovy作为模板引擎

发布时间：2020-12-14 16:34:49 所属栏目：大数据来源：网络整理

导读：从他们的网站 http://www.playframework.org/documentation/1.0/faq “ 目前Play堆栈中最大的CPU消费者是基于Groovy的模板引擎.但是,随着Play应用程序的轻松扩展,如果您需要提供极高的流量,那么这并不是一个问题：您可以平衡多个服务器之间的负载.我们希望通

从他们的网站 http://www.playframework.org/documentation/1.0/faq

“
目前Play堆栈中最大的CPU消费者是基于Groovy的模板引擎.但是,随着Play应用程序的轻松扩展,如果您需要提供极高的流量,那么这并不是一个问题：您可以平衡多个服务器之间的负载.我们希望通过新的JDK7和更好地支持动态语言来提升这一级别的性能.
“

那么没有更好的选择？ JSP怎么样？

解决方法

JSP是不可行的,因为每个JSP编译为Servlet,servlet API提供的服务器端会话与RESTful范例不兼容.我们不想回到不可靠的服务器端会话的黑暗时代,浏览器中的按钮问题,转发等.

Japid模板很有趣,但它们不是一个伟大的社区的支持,甚至在创建游戏时甚至不存在(我不知道肯定).我尝试Japid作为我自己的应用程序中的Groovy模板的替代品,并在JMeter测试中发现,该优点将仅为边际,最大为10％. 25％改善.

我想最终这一切都取决于你的可扩展性要求和你的页面的结构.我选择了90％的应用程序用例,并进行了测试.对我来说,这个小的改进并不足以证明额外依赖的额外成本(我喜欢将依赖关系维持在最低限度).

Groovy模板一般不坏或慢.尽可能使用类型化的变量(而不是“def”),即使在关闭中！将访问的属性的值保留在局部变量中.寻找合理的结果.然后保持你的手指交叉,GSP将来可能会在groovy运行,你完成了;)

对我来说,这个问题不是为什么他们在意见中使用groovy.也就是说,因为我宁愿在控制器层中错过它. Groovy会使编码控制器的行为更容易IMHO.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!