scala play2 mySQL_scala-比较Play2与Lift

在Lift上花了一两个星期后才发布此消息为任何人的利益服务。 但是，我想花一些时间来纠正一些错误和误解。

为了安全起见，我认为这不是框架的工作。

你错了 安全是框架的工作。 安全至关重要默认情况下完成，而不是依靠每个开发人员来了解每个安全漏洞，并确保每一行代码都将其考虑在内。

我们要做的就是看看GitHub发生了什么理解即使是最好的编码员也使用众所周知的技术会犯一个严重的错误。

Lift在顶部提供了坚实的安全层，因此默认情况下没有XSS，CSRF等。但是开发人员可以根据自己的意愿深入挖掘HTTP请求并进行处理与线上的字节。

无状态/有状态：很难说出主要区别在哪里。 我只知道如果您使用网络套接字，播放也会有状态。

Lift非常清楚您需要的状态和不需要的状态。 升降机可以支撑无状态，部分有状态和完全有状态的应用。 在逐页和根据请求的不同，Lift应用可以是有状态的或无状态的(例如，在Foursquare中，场所页面对于搜索引擎抓取，但对于已登录的浏览器而言为有状态。)有关状态的设计决策的更多信息，请参见提升，状态和缩放。

两个框架都使用sbt

Lift使用Maven，sbt，Buildr甚至Ant。 升降机与构建环境无关以及有关部署环境(Java EE容器，Netty等)的信息。 这个很重要因为它使Lift更易于与您的其他环境集成。

Lift带有授权，但我认为有一个play2 scala插件可以执行相同的操作

电梯已有5多年的历史了，它有很多模块和东西。 Lift Web框架(与模块不同)与持久性，身份验证等无关，因此您可以在Lift上使用任何东西。

异步-播放2使用Akka。 不知道电梯使用什么，但它们也有类似的东西。

Lift拥有Async支持已超过5年。 它已融入框架中。 Lift的Comet支持是所有Web框架中最好的，因为，除其他外，它通过单个请求在页面上复用所有“推送”请求到服务器，避免了连接短缺。 Lift如何做到异步不太重要，因为Lift的核心理念之一是我们删除了从开发人员那里获取资源，以便开发人员可以专注于业务逻辑。

但是对于那些关心的人，Lift拥有所有框架中最好，最轻的角色斯卡拉土地。 我们是第一个脱离Scala Actor图书馆的人，为允许Akka和ScalaZ Actor的不同Actor库开创先河蓬勃发展。

在CSRF支持下吊装船。 Play2具有CSRF的模块，但这为您的代码增加了样板。

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

无状态身份验证似乎具有一些安全漏洞。 这两个框架都具有状态认证。 (play2有状态/无状态，解除有状态)

Lift应用程序可以根据需要具有状态或无状态。 这是你的选择，举重明确说明了如何做出决定。

而且，正如我在“提升，状态和缩放”帖子中指出的那样，开发人员可以弄清楚如何以安全，可扩展，高性能的方式序列化状态(因为实际上网络上的每个请求识别特定用户有状态的应用)应该以可预测的方式完成，框架的安全方式，并为开发人员提供合理的替代。

分手笔记

Play就像Rails：快速将网站组合在一起，基于MVC，所以很多开发人员都了解它。 但是Play缺乏Rails的深度和广度(社区，插件，专业知识，才能等)需要快速，简单的MVC，然后使用Rails和JRuby并编写您的在Scala的后端(他们的协作异常出色。)

提拉是另一种野兽。 有一个重要的学习曲线(停止思考)MVC，并首先考虑流向业务逻辑的用户体验。)但是，一旦您走上了学习的弯路，Lift网站将变得更加安全，高度可扩展，超级交互，并且随着时间的推移更容易维护。