151

我知道这个问题有点开放，但我一直在将 Scala/Lift 视为 Java/Spring 的替代品，我想知道 Scala/Lift 相对于它的真正优势是什么。从我的角度和经验来看，Java Annotations 和 Spring 确实最大限度地减少了您必须为应用程序执行的编码量。Scala/Lift 对此有改进吗？

4

10 回答 10

229

我不得不说我非常不同意 Dan LaRocque 的回答。

电梯不是单一的。它由离散元素组成。它不会忽略 J/EE 元素，它支持 JNDI、JTA、JPA 等。事实上，您不会被迫使用这些 J/EE 元素，这有力地表明了 Lift 的模块化设计。

  • Lift 的观点理念是“让开发者决定”。Lift 提供了一种不允许在视图中包含任何逻辑代码的模板机制，一种基于执行 Scala 代码和 Scala 的 XML 文字的视图机制，以及一种基于Scalate的视图机制。如果您选择 XML 模板机制，那么您可以选择标记在您的业务逻辑中属于多少（如果有）。Lift 的视图分离比 Spring 提供的任何东西都强，因为您无法在 Lift 的 XML 模板中表达任何业务逻辑。
  • Lift 的 Object ↔ Persistence 理念是“让开发人员决定”。Lift 有 Mapper，它是一个 ActiveRecord 风格的对象关系映射器。它可以完成小型项目的工作。电梯支持 JPA。Lift 有一个 Record 抽象，支持将对象进出关系数据库，进出 NoSQL 存储（Lift 包括对 CouchDB 和 MongoDB 的本机支持，但适配器层是几百行代码，所以如果你想要 Cassandra 或别的东西，得到它不是很多工作。）基本上，Lift Web 框架不依赖于对象如何物化到会话中。此外，会话和请求周期是开放的，因此将事务挂钩插入请求/响应周期很简单。
  • Lift 的理念是“服务器团队需要了解一种语言，而不是多种语言”。这意味着配置是通过 Scala 完成的。这意味着我们不必以 XML 语法实现 40% 的 Java 语言结构来创建灵活的配置选项。这意味着编译器语法和类型检查配置数据，因此您不会在运行时得到任何奇怪的 XML 解析或不正确的数据。In 意味着您不必拥有能够根据您正在使用的库了解您正在使用的注释细节的 IDE。
  • 是的，Lift 的文档并不是它的强项。

说了这么多，再说说Lift的设计理念。

在开始编写 Lift 之前，我编写了Web 框架宣言。在很大程度上，并且比我所知道的任何其他 Web 框架都更大，Lift 满足了这些目标。

Lift 的核心是试图抽象出 HTTP 请求/响应周期，而不是在 HTTP 请求周围放置对象包装器。在实际层面上，这意味着用户可以执行的大多数操作（提交表单元素、执行 Ajax 等）都由浏览器中的 GUID 和服务器上的函数表示。当 GUID 作为 HTTP 请求的一部分呈现时，将使用提供的参数应用（调用）该函数。由于 GUID 难以预测且特定于会话，因此使用 Lift 进行重放攻击和许多参数篡改攻击比大多数其他 Web 框架（包括 Spring）要困难得多。这也意味着开发人员的工作效率更高，因为他们专注于用户操作和与用户操作相关的业务逻辑，而不是打包和解包 HTTP 请求的管道。

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

就是这么简单。因为在创建函数时friendRequest在作用域内，所以函数在作用域上关闭了……不需要暴露朋友请求的主键或做任何其他事情……只需定义按钮的文本（它可以本地化，也可以从 XHTML 模板中提取，也可以从本地化模板中提取）以及按下按钮时要执行的函数。Lift 负责分配 GUID、设置 Ajax 调用（通过 jQuery 或 YUI，是的，您可以添加自己喜欢的 JavaScript 库）、使用回退进行自动重试、通过排队 Ajax 请求来避免连接不足等。

因此，Lift 和 Spring 之间的一大区别在于，Lift 与功能相关的 GUID 理念具有更好的安全性和更好的开发人员生产力的双重好处。GUID -> 函数关联已被证明非常耐用......相同的构造适用于普通表单、ajax、comet、多页向导等。

Lift 的下一个核心部分是尽可能长时间地保留高级抽象。在页面生成方面，这意味着将页面构建为 XHTML 元素并将页面保持为 XHTML，直到流响应之前。好处是抵抗跨站脚本错误，在页面组成后将 CSS 标记移动到页面头部和脚本到页面底部的能力，以及基于目标浏览器重写页面的能力。在输入端，可以重写 URL 以以类型安全的方式提取参数（查询和路径参数），高级的安全检查数据可用于在请求周期的早期进行处理。例如，以下是定义 REST 请求服务的方法：

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

使用 Scala 的内置模式匹配，我们匹配传入的请求，提取路径的第三部分并获取与该值对应的用户，甚至应用访问控制检查（当前会话或请求是否有权访问给定的用户记录）。因此，当 User 实例到达应用程序逻辑时，它已经过审查。

凭借这两个核心部件，Lift 在安全性方面具有巨大优势。为了让您了解 Lift 不妨碍功能的安全性程度，为 Yahoo! 提供安全性的Rasmus Lerdorg 关于 FourSquare（Lift 海报子网站之一）有这样的说法：

给@foursquare的四颗星 - 一段时间以来的第一个站点

当时，FourSquare 有一名工程师在编写代码（并不是说@harryh 不是超级天才），他的主要重点是重写 FourSquare 的 PHP 版本，同时应对每周翻倍的流量。

Lift 安全重点的最后一部分是 SiteMap。它是一个统一的访问控制、站点导航和菜单系统。开发人员使用 Scala 代码（例如If(User.loggedIn _)或If(User.superUser _)）为每个页面定义访问控制规则，并且在任何页面呈现开始之前应用这些访问控制规则。这很像 Spring Security，除了它从项目一开始就被烘焙，并且访问控制规则与应用程序的其余部分统一，因此您不必在 URL 时更新 XML 中的安全规则的过程更改或计算访问控制更改的方法。

总而言之，Lift 的设计理念为您提供了访问控制、抵御 OWASP 十大安全漏洞、更好的 Ajax 支持和比 Spring 更高的开发人员生产力的好处。

但是 Lift 还为您提供了对任何 Web 框架的最佳 Comet 支持。这就是 Novell 选择 Lift 为其Pulse 产品提供动力的原因，以下是 Novell 对 Lift 的评价：

Lift 是一种 Web 框架，可让您作为开发人员专注于全局。强大、富有表现力的打字和更高级别的功能（如内置 Comet 支持）使您可以专注于创新而不是管道。构建像 Novell Pulse 这样的丰富的实时 Web 应用程序需要一个具有 Lift 强大功能的框架。

所以，Lift 不只是另一个模仿的 MVC 框架。这是一个框架，其背后有一些已经非常成熟的核心设计原则。它是一个具有安全性和开发人员生产力双重优势的框架。Lift 是一个分层构建的框架，可根据开发人员的需求为开发人员提供正确的选择……视图生成的选择、持久性的选择等。

Scala 和 Lift 为开发人员提供了比 XML、注释和其他构成 Spring 的习惯用法更好的体验。

于 2010-06-18T05:07:41.037 回答
113

假设我们对 Scala 和 Java 同样熟悉，忽略（巨大的）语言差异，除非它们与 Spring 或 Lift 有关。

Spring 和 Lift 在成熟度和目标方面几乎截然相反。

  • Spring 比 Lift 大约大 5 年
  • Lift 是单一的，只针对网络；Spring 是模块化的，面向 Web 和“常规”应用程序
  • Spring 支持大量的 Java EE 特性；电梯忽略了那些东西

一句话，Spring是重量级的，Lift是轻量级的。有足够的决心和资源，你可以扭转局面，但你需要两者兼而有之。

在使用这两个框架后，我想到了以下具体差异。这不是一个详尽的列表，无论如何我都无法编译。正是我觉得最有趣的事情......

  1. 查看理念

    Lift 鼓励在片段/动作方法中放置一些视图材料。片段代码尤其会散布以编程方式生成的表单元素、<div>s、<p>s 等。

    这是强大而有用的，特别是因为 Scala 具有内置的语言级 XML 模式。可以在 Scala 方法中内联编写 XML，包括大括号中的变量绑定。这对于非常简单的 XML 服务或服务模型来说是令人愉快的——您可以在一个非常简洁的文件中完成一组 HTTP 响应操作，而无需模板或大量附带配置。缺点是复杂性。根据你走多远，视图和逻辑之间的关注点要么模糊分离，要么没有分离。

    相比之下，在 webapps 中经常使用 Spring 会强制将视图与其他所有内容分开。我认为 Spring 支持多个模板引擎，但我只在任何严肃的事情上使用过 JSP。使用 JSP 进行受 Lift 启发的“模糊 MVC”设计将是疯狂的。这对大型项目来说是一件好事，因为阅读和理解的时间可能会让人不知所措。

  2. 对象关系映射器选择

    Lift 的内置 ORM 是“Mapper”。有一个即将推出的替代品，叫做“Record”，但我认为它仍然被认为是 pre-alpha。LiftWeb Book 中有关于使用 Mapper 和 JPA 的部分。

    Lift 的CRUDify功能虽然很酷，但仅适用于 Mapper（而不是 JPA）。

    当然，Spring 支持一整套标准和/或成熟的数据库技术。那里的操作词是“支持”。理论上，您可以将任何 Java ORM 与 Lift 一起使用，因为您可以从 Scala 调用任意 Java 代码。但是 Lift 只真正支持 Mapper 和（在较小程度上）JPA。此外，在 Scala 中使用非平凡的 Java 代码目前并不像人们想象的那样无缝；使用 Java ORM，您可能会发现自己要么在任何地方同时使用 Java 和 Scala 集合，要么将所有集合转换进出 Java 组件。

  3. 配置

    Lift 应用程序几乎完全通过应用程序范围的“引导”类的方法进行配置。换句话说，配置是通过 Scala 代码完成的。这非常适合具有简短配置的项目，并且当进行配置的人能够轻松地编辑 Scala 时。

    Spring 在配置方面非常灵活。许多 conf 选项可以通过 XML 配置或注释来驱动。

  4. 文档

    Lift 的文档很年轻。Spring 的文档非常成熟。没有比赛。

    由于 Spring 的文档已经组织得很好并且很容易找到，我将回顾一下我为 Lift 找到的文档。基本上有 4 个 Lift 文档来源：LiftWeb Book、API Docs、LiftWeb 的Google group和“入门”。还有一套不错的代码示例，但我不会将它们本身称为“文档”。

    API 文档不完整。LiftWeb Book 已经出版在树上，但它也可以在线免费获得。它真的很有用，尽管它绝对的说教风格有时会激怒我。教程有点长，合同有点短。Spring 有一个适当的手册，而 Lift 缺乏。

    但是 Lift 确实有一组很好的例子。如果您能够轻松阅读 Lift 代码和示例代码（并且您已经非常了解 Scala），那么您可以在相当短的时间内完成工作。

这两个框架都很引人注目。有很多应用程序可供您选择并做得很好。

于 2010-04-22T01:06:48.140 回答
11

我建议你检查一下 play framework，它有一些非常有趣的想法，并且支持 Java 和 Scala 的开发

于 2010-04-24T01:24:49.473 回答
10

纯娱乐。为了学习新的编程方法。

于 2010-04-21T14:42:36.177 回答
10

我强烈研究了将 Lift 用于最近的一个 Web 项目，而不是 Spring MVC 的忠实粉丝。我没有使用过最新版本，但是 Spring MVC 的早期版本让您跳过很多障碍才能运行 Web 应用程序。我几乎在 Lift 上被卖掉了，直到我看到 Lift 可能非常依赖会话并且需要“粘性会话”才能正常工作。摘自http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

在出现标准会话复制技术之前，您仍然可以使用“粘性会话”对应用程序进行集群。这意味着与 HTTP 会话有关的所有请求都必须由同一个集群节点处理

因此，一旦需要会话，用户就必须固定到该节点。这产生了对智能负载平衡的需求并影响了扩展，这使得 Lift 无法成为我的解决方案。我最终选择了http://www.playframework.org/并且非常高兴。到目前为止，Play 一直稳定可靠，并且非常易于使用。

于 2012-03-15T19:37:12.867 回答
7

我不是从 Java 背景来到 Lift 和 Scala，所以这不是个人经验，但我知道许多 Lift 开发人员发现 Scala 是一种比 Java 更简洁和高效的语言。

于 2010-04-21T19:27:58.527 回答
3

扩展你的知识总是一个值得的努力:) 我刚开始学习 Scala，它影响了我编写普通 Java 的方式，我可以说它到目前为止非常有益。

于 2010-04-21T15:37:08.533 回答
3

我讨厌完全让你的世界陷入困境。但是你可以在一个应用程序中使用 Scala、Java、Lift、Spring 并且让它不成问题。

于 2010-04-23T21:33:43.793 回答
0

但主要问题是我们不能将弹簧与升力进行比较。Lift 基本上用作 UI 框架，而 Spring 用作 DI 框架。
如果您正在开发具有那么多后端的 Web 应用程序，请确保您可以使用 Lift。
但是，如果您正在开发的 Web 应用程序具有一些系列后端并且您定义需要转到 spring。

于 2012-11-06T14:51:57.167 回答
0

在我看来，想象力才是最重要的。

假设您想编写一个应用程序。如果您是一位体面的开发人员，那么您应该已经在脑海中构建了该应用程序。下一步是通过代码发现它是如何工作的。为此，您需要将想象中的应用程序传递给将其转换为现实世界应用程序的函数。该函数是一种编程语言。所以

Real app = programming language (imagined app)

所以语言的选择很重要。框架也是如此。这里有很多聪明人会建议你选择什么，但最终，最能体现你想象力的语言/框架应该是你的选择。因此，两者都制作原型并做出选择。

至于我，我正在慢慢学习 Scala 和 Lift，并喜欢它。

于 2012-03-25T11:27:57.720 回答