比较提升与Play2
我以前用java的play2。 这感觉有点像样板，特别是如果你用java与akka。 但这不是框架的错误。
昨天我读“斯卡拉不耐烦”，我真的很喜欢这种语言。
现在我看了两个框架Lift 2.5和Play 2.0.3。 我认为电梯有更高的学习曲线，我不能只是做一些事情。 这不适合我。 从我看到的，Lift有一个非常漂亮和干净的devise。
但对我而言，很难说出主要的差异。 我认为这两个框架都很棒。
-
视图优先的方法不允许你在你的模板中编码，而是你必须在代码片段。 我很喜欢这个，因为它看起来更有组织性。 它也让你使用一个正常的HTML编辑器。 （我没有太多的经验，这只是我的第一印象）
-
为了安全起见，我不认为这是框架的工作。
-
无状态/有状态：很难区分主要区别在哪里。 我只知道如果你使用networking套接字，游戏也有一个状态。
-
按F5后，这两个框架都能够编译。 我非常喜欢这个function。
-
这两个框架都使用sbt
-
电梯来与授权，但我认为有一个play2斯卡拉插件，做同样的事情
-
Lift有一个用于mongoDB的ORM映射器。 因为我想使用noSQL，这对我来说看起来更清洁。 （再次没有太多的经验） 编辑有一个scala mongodb在play2的ORM映射器https://github.com/leon/play-salat
-
asynchronous – 播放2使用Akka。 不知道电梯使用什么，但他们也有类似的东西。
-
Lift提供CSRF支持。 Play2有一个CSRF模块，但是这样会为您的代码添加样板。
-
无状态身份validation似乎有一些安全漏洞。 这两个框架都有状态validation。 （play2有状态/无状态，电梯有状态）
- 每个框架的优点是什么？
使用Lift之后花一两个礼拜的时间发布，并不符合任何人的兴趣。 但是，我想花些时间纠正一些错误和误解。
- 为了安全起见，我不认为这是框架的工作。
你是错的 安全是框架的工作。 默认情况下安全性至关重要，而不是依靠每个开发人员来了解每个安全漏洞，并确保每一行代码都考虑到这一点。
我们所要做的就是看看GitHub发生了什么事情，即使是使用众所周知的技术的最好的编程人员也可能犯下严重的错误。
Lift在顶层提供了一个可靠的安全层，所以默认情况下，没有XSS，CSRF等，但开发人员可以根据需要深入挖掘HTTP请求，并处理线路上的字节。
- 无状态/有状态：很难区分主要区别在哪里。 我只知道如果你使用networking套接字，游戏也有一个状态。
电梯非常清楚你需要什么状态，哪里不需要。 Lift可以支持无状态，部分有状态和完全有状态的应用程序。 在逐页和请求请求的基础上，电梯应用程序可以是有状态的或无状态的（例如，在Foursquare中 ，场所页面对于search引擎抓取是无状态的，但对于login的浏览器是有状态的）。有关状态的devise决定的更多信息，请参阅提升，状态和缩放 。
- 这两个框架都使用sbt
Lift使用Maven，sbt，Buildr，甚至Ant。 Lift对于构build环境和部署环境（Java EE容器，Netty等等）是不可知的。 这很重要，因为它使Lift更容易与其他环境集成。
- 电梯来与授权，但我认为有一个play2斯卡拉插件，做同样的事情
Lift已经有5年多的时间了，它有很多模块和东西。 Lift Web框架（与模块不同）对于持久性，身份validation等是不可知的，因此您可以使用Lift来使用任何东西。
- asynchronous – 播放2使用Akka。 不知道电梯使用什么，但他们也有类似的东西。
Lift已经有超过5年的asynchronous支持。 它被烧入框架。 Lift的Comet支持是任何Web框架中最好的支持，因为它通过单个请求将页面上的所有“推送”请求多路复用到服务器，避免了连接不足。 Lift如何实现asynchronous是不太重要的，因为Lift的核心理念之一是我们从开发人员中删除了pipe道，因此开发人员可以专注于业务逻辑。
但是对于那些关心的人来说，Lift拥有Scala-land中任何框架的最重和最轻的参与者。 我们是第一个脱离斯卡拉演员的图书馆，并努力开拓不同的演员图书馆，使阿卡和斯卡拉演员蓬勃发展。
- Lift提供CSRF支持。 Play2有一个CSRF模块，但是这样会为您的代码添加样板。
这是Lift对安全承诺的一部分。 这很重要 。
- 无状态身份validation似乎有一些安全漏洞。 这两个框架都有状态validation。 （play2有状态/无状态，电梯有状态）
提升应用程序可以是有状态的或无状态的，只要你想。 这是您的select，Lift很清楚如何做出决定。
另外，正如我在Lift，State和Scaling中所指出的那样，让开发人员弄清楚如何以安全，可伸缩，高性能的方式来序列化状态（因为几乎每个Web应用程序的识别特定用户的请求都是有状态的）通过框架以可预测，安全的方式完成，为开发人员提供合理的覆盖。
注意事项
Play就像Rails一样：把网站搞得一团糟，它是基于MVC的，所以很多开发者都明白这一点。 但是，Play缺乏Rails的深度和广度（社区，插件，专业知识，人才等）。如果你想要快速，简单的MVC，那么使用Rails和JRuby并在Scala中编写你的后端（他们一起工作非常好）。
电梯是一个不同的野兽。 有一个显着的学习曲线（停止思考MVC，并开始思考用户体验，首先stream向业务逻辑）。但是，一旦你到了学习曲线，电梯网站更安全，高度可扩展，超级互动，更容易保持一段时间。
要了解Play可以做些什么（可以很酷），请看看TypeSafe控制台
要使用Lift快速启动，请使用模板项目 。
有关使用Mongo with Play的示例，请看一下Factile 。
总的来说，我认为你们不会在电梯或游戏中出错。 两者都是积极的项目，有良好的社区和作者的良好支持。 这真的取决于你的业务问题。 如果工具支持对你来说很重要，那么你可能想要使用Play（它在IntelliJ Idea中得到很好的支持）。
请注意，作为TypeSafe技术堆栈的一部分，Play将构build到最新版本的Scala，因此如果使用Scala 2.10function对您很重要，那么您可能需要牢记这一点。 Lift目前正在使用Scala 2.9.2，这也很好。
对于我目前的项目，我使用ORM（这是伟大的，坚如磐石）的升降图，用喷射REST（这简直太神奇了）。 这种方法完全避免了框架，但是取决于你想要做什么。 框架往往是要走的路。
