与Play2相比较Lift

Question

我之前使用过java的play2框架，如果你和java一起使用akka，则会感到有点像样板文件。但这不是框架的错。

昨天我读了《Scala for the impatient》，我真的很喜欢这门语言。

现在我看了Lift 2.5和Play 2.0.3这两个框架。我认为Lift的学习曲线更高，我不能仅通过Lift做一些事情。对我来说这不是缺点。从我所看到的，Lift有一个非常好看和干净的设计。

但对我而言，很难说它们主要的区别是什么。我认为两个框架都很棒。

• 视图优先的方法不允许您在模板中编写代码，而是必须在片段中编写代码。我很喜欢这个，因为它看起来更有组织性。它还可以让您使用普通的html编辑器。 （我没有太多经验，这只是我的第一印象）

• 关于安全性，我不认为这是框架的工作。

• 无状态/有状态：很难说主要区别在哪里。我只知道如果使用web socket，则play也有状态。

• 按下F5后，两个框架都可以编译。我非常喜欢这个功能。

• 两个框架都使用sbt

• Lift附带授权，但我认为play2 scala插件也可以完成同样的事情。

• Lift具有用于mongoDB的ORM mapper。因为我想使用noSQL，所以这看起来更干净。（再次强调没有太多经验） 编辑 在play2中有一个ORM mapper for scala mongodb：https://github.com/leon/play-salat

• 异步- Play 2使用Akka。不知道Lift使用什么，但他们也有类似的东西。

• Lift附带CSRF支持。Play2有一个CSRF模块，但这会添加样板文件到您的代码中。

无状态认证似乎存在某些安全漏洞。这两个框架都采用有状态认证。(play2 有状态/无状态，lift 有状态)

---

• 每个框架的优势是什么？

- Maik Klein

---

我可以建议您删除关于您想要做什么的部分吗？您仍然可以开设第二个问题，询问“哪个对我好？”并保留“有什么区别？”因为后者似乎更有趣，可以作为其他人的参考。 - Frank

Answer 1

在使用Lift一两周后发布这篇文章并不真正为任何人的利益服务。然而，我想花些时间纠正一些错误和误解。

• 关于安全性，我认为这不是框架的工作。

你错了。安全是框架的职责。关键是默认情况下必须完成安全性，而不是依赖每个开发者理解每个安全漏洞并确保每行代码都考虑到这一点。

我们只需要看看GitHub发生的事情，就可以理解即使是最好的程序员使用众所周知的技术也可能犯一个致命的错误。

Lift在顶层提供了一个坚实的安全层，因此默认情况下没有XSS、CSRF等问题，但开发人员可以深入挖掘HTTP请求并处理传输中的字节。

• 无状态/有状态：很难确定主要区别在哪里。我只知道如果使用Web套接字，Play也有状态。

Lift非常清楚您需要哪些状态以及不需要哪些状态。Lift可以支持无状态，部分有状态和完全有状态的应用程序。在按页面和请求方式的基础上，Lift应用程序可以是有状态或无状态的（例如，在Foursquare中，场馆页面对于搜索引擎爬行是无状态的，但对于已登录的浏览器是有状态的）。有关状态设计决策的更多信息，请参见Lift，State和Scaling。

• 两个框架都使用sbt

Lift使用Maven，sbt，Buildr甚至Ant。Lift对构建环境和部署环境（Java EE容器，Netty等）是不可知的。这很重要，因为它使Lift更容易与您的其他环境集成。

• Lift带有授权功能，但我认为有一个play2 scala插件可以做同样的事情

“Lift”已经存在5年以上，有很多模块和相关内容。与模块不同，“Lift”Web框架对持久性、身份验证等没有偏见，因此您可以使用任何东西来配合“Lift”。

• 异步 - Play 2使用Akka。不知道“Lift”使用了什么，但他们也有类似的东西。

“Lift”支持异步已有5年以上的历史。它被整合到框架中。“Lift”的Comet支持是任何Web框架中最好的，因为它将页面上所有的“推送”请求通过单个请求复用到服务器，从而避免了连接饥饿问题。“Lift”如何处理异步并不是很重要，因为“Lift”的核心理念之一就是我们会为开发者减少繁琐的工作，让开发者专注于业务逻辑。

但是对于那些关心的人，“Lift”具有Scala界中最好且最轻量级的Actor。我们是第一个脱离Scala Actor库的框架，并致力于开创不同Actor库的先河，这使得Akka和ScalaZ Actors得以繁荣发展。

• Lift支持CSRF。Play2有一个CSRF模块，但这会给您的代码添加样板。

这是Lift承诺安全性的一部分。这很重要。

• 无状态身份验证似乎存在某些安全漏洞。两个框架都具有有状态身份验证。（play2有状态/无状态，lift有状态）

Lift应用程序可以根据您的需要是有状态的或无状态的。这是您的选择，Lift非常清楚如何做出决策。

此外，正如我在Lift、状态和扩展帖子中指出的那样，使开发人员找出如何以安全、可扩展、高效的方式序列化状态（因为几乎每个识别特定用户的Web应用程序请求都是有状态的）应该由框架以可预测、安全的方式完成，并为开发人员提供合理的覆盖。

结束语

Play很像Rails：它可以快速搭建网站，基于MVC模式，因此很多开发者都能理解。但是相比于Rails（社区、插件、专业知识、人才等方面），Play缺乏深度和广度。如果你需要快速简单的MVC，那么使用Rails和JRuby，在Scala中编写后端（它们非常搭配）。

Lift则大不相同。有一个显著的“取消学习曲线”（停止考虑MVC，首先考虑流向业务逻辑的用户体验）。但是一旦你通过了取消学习曲线，Lift网站会更加安全、高度可伸缩、超级交互，并且随着时间的推移更容易维护。

- David Pollak

---

提到Lift时确实是另一种不同的东西，这可能是TypeSafe选择采用Play和Slick而不是Mapper等的原因。像Rails一样，Play是一个开放的门户，每个人都可以“理解”它，但与Rails不同的是，Play非常快速、可扩展、直观和简单好用。将Play硬生生地塞进简单的MVC（暗示不适用于复杂情况）视角中，并与Rails/JRuby/Scala混合在一起——这就是纯粹的恐吓手段。 - virtualeyes

不，Typesafe采用了Play是因为我决定不与Typesafe合作，并拒绝了他们的联合邀约。Play是他们唯一的真正替代品，但它很薄弱。 - David Pollak

Robin，David 在很多场合都多次表明他并没有“离开” Lift。他仍在提交代码并在 Google 群组中回答问题。实际上，这样一个巨大的头脑参与多个项目/多种语言只有好处。每个项目都因此受益——因为 David 可以始终比较/添加东西/入侵，并从不同社区/项目中获得经验。 - Meglio

@RobinGreen 不要散布谎言。我从未“离开” Lift 社区。是的，我有其他项目和在不同语言上的工作。我所做的是停止担任 Lift 的终身仁慈独裁者。Lift 已经成长超越了一个人，而 2.5-M4 版本的发布没有我也是一种优势而非弱点。Lift 社区中有很多聪明的头脑... 我只是让 Lift 成为现在样子的众多人之一。但我积极地编写 Lift 代码并积极参与 Lift 社区。 - David Pollak

@DavidPollak，我为不准确地描述发生的事情并在写下评论之前没有回去核实理解而道歉。我曾经假设由于您创建了这个新项目Visio，您会将大部分时间投入其中，因此从那时起您在Lift项目中的参与将很少。显然，事实并非如此。 - Robin Green

Answer 2

想要了解 Play 的功能 (非常酷)，可以查看TypeSafe控制台

如果想快速上手 Lift，可以使用模板项目

想了解在 Play 中使用 Mongo 的示例，请看Factile

总之，选择 Lift 还是 Play 都不会错。它们都是活跃的项目，拥有良好的社区和作者的支持。这真的取决于你的业务问题。如果你重视工具支持，那么你可能需要考虑使用 Play（在 IntelliJ Idea 上得到很好的支持）。

请注意，Play 是 TypeSafe 技术栈的一部分，因此将构建到最新版本的 Scala，所以如果对您来说使用 Scala 2.10 功能很重要，那么您可能需要记住这一点。Lift 目前使用的是 Scala 2.9.2，也很好。

对于我的当前项目，我使用 lift-mapper 进行 ORM（非常出色和稳定），使用 Spray 进行 REST（非常棒）。这种方法避免了所有的框架，但这取决于您想做什么。通常情况下，框架是可行的选择。

- Jack

---

仅供参考，我已经在2.10 M7上构建了Lift的所有主要部分（包括mapper），并且我个人在生产中使用它。不过，我还没有运行大多数测试，所以无法保证其使用。在https://github.com/lift/framework/tree/nafg_wip_scala210可以找到相关内容。 - nafg

Play框架真是太烦人了，他们经常引入破坏性变更，如果你升级了一个小版本，你的网站就会崩溃。 - qed