为什么我会在Java/Spring上使用Scala/Lift？[已关闭]

我不得不说，我强烈反对Dan LaRocque的答案。

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

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

综上所述，让我谈谈Lift的设计理念。

在我开始写Lift之前，我写了Web Framework Manifesto。在很大程度上，在某种程度上，Lift满足了这些目标，而且程度比我所知道的任何其他Web框架都要大。

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

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，彗星，多页向导等。

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 - 一段时间以来的第一个网站，我已经仔细研究了没有一个安全问题（我可以找到） - http://twitter.com/rasmus/status/5929904263

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

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

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

但是Lift还为您提供了任何Web框架的最佳Comet支持。这就是为什么Novell选择Lift为他们的Pulse产品提供动力，以下是Novell对Lift的看法：

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

因此，Lift不仅仅是另一个me-too MVC框架。这是一个框架，它背后有一些核心设计原则，这些原则已经非常成熟。这是一个框架，具有安全性和开发人员生产力的双重优势。Lift是一个内置层的框架，可根据开发人员的需求为他们提供正确的选择...视图生成的选择、持久性的选择等

Scala和Lift为开发人员提供了比组成Spring的XML，注释和其他习语更好的体验。

让我们假设我们在Scala和Java中同样舒适，并忽略（巨大的）语言差异，除非它们与Spring或Lift有关。

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

• 春天比电梯大五岁左右
• 升降机是单片的，只针对网络;Spring是模块化的，针对Web和“常规”应用程序
• Spring支持大量的Java EE功能;电梯忽略了这些东西

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

以下是使用这两个框架后一直留在我脑海中的具体差异。这不是一个详尽的列表，无论如何我都无法编译。对我来说最有趣的是...

1. 查看理念

   Lift 鼓励在代码段/操作方法中放置一些视图材料。特别是代码片段将洒上以编程方式生成的表单元素，s，s等。<div><p>

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

   相比之下，在Web应用程序中经常使用Spring会强制视图与其他所有内容之间保持强烈的分离。我认为Spring支持几个模板引擎，但我只在任何严肃的事情上使用JSP。用JSP做一个受Lift启发的“模糊MVC”设计将是疯狂的。这在大型项目中是一件好事，在大型项目中，阅读和理解的时间可能是压倒性的。

2. 对象关系映射器选择

   Lift的内置ORM是“Mapper”。有一个即将到来的替代方案叫做“记录”，但我认为它仍然被认为是前阿尔法。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. 配置

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

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

4. 文档

   Lift的文档很年轻。Spring的文档非常成熟。没有竞争。

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

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

   但Lift确实有一组很好的例子。如果你喜欢阅读Lift代码和示例代码（并且你已经很了解Scala），你可以在相当短的时间内解决问题。

这两个框架都很引人注目。有各种各样的应用程序，你可以选择其中任何一个并做得很好。