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

我知道这个问题有点悬而未决，但是我一直在将Scala / Lift视为Java / Spring的替代品，我想知道Scala / Lift在此之上的真正优势是什么。从我的观点和经验来看，Java Annotations和Spring确实最小化了您为应用程序要做的编码量。Scala / Lift是否会对此有所改善？

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

在成熟度和目标方面，Spring和Lift几乎完全相反。

• 春天比Lift大五岁
• 提升是整体的，仅针对网络；Spring是模块化的，同时针对Web和“常规”应用程序
• Spring支持大量的Java EE功能。升降机忽略了这些东西

一句话，Spring是重量级的，Lift是轻量级的。有了足够的决心和资源，您就可以轻而易举地做到这一点，但您同时需要很多。

在使用这两个框架之后，我想到的是具体的差异。这不是一个详尽的清单，无论如何我都无法编译。对我来说最有趣的事情就是...

1. 查看哲学

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

   这功能强大且有用，特别是因为Scala具有内置的语言级XML模式。可以在Scala方法中内联编写XML，包括括号中的变量绑定。对于非常简单的XML服务或服务模型，这可能会很令人愉悦-您可以在一个出色的简洁文件中敲击一套HTTP响应操作，而无需模板或进行大量的配置。缺点是复杂性。根据您走的远近，视图和逻辑之间的关注点可能模糊分离，或者没有分离。

   相比之下，针对Web应用程序的Spring常规使用会在视图与其他所有内容之间形成强烈的分隔。我认为Spring支持多个模板引擎，但是我只在严重的情况下使用过JSP。用JSP进行Lift启发的“模糊MVC”设计会很疯狂。对于大型项目来说，这是一件好事，在这里，阅读和理解的时间可能会非常大。

2. 对象关系映射器选择

   Lift的内置ORM是“映射器”。有一个即将到来的替代方法称为“记录”，但我认为它仍被认为是预Alpha版。LiftWeb手册包含有关同时使用Mapper和JPA的部分。

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

   当然，Spring支持一系列标准和/或成熟的数据库技术。那里的执行词是“支持”。从理论上讲，您可以将任何Java ORM与Lift一起使用，因为您可以从Scala调用任意Java代码。但是Lift仅真正支持Mapper和（在较小程度上）JPA。另外，在Scala中使用不平凡的Java代码目前还不如人们所希望的那样无缝。使用Java ORM，您可能会发现自己在任何地方都使用Java和Scala集合，或者将所有集合转换进Java组件或从Java组件转换出来。

3. 组态

   提升应用几乎完全通过应用范围的“启动”类的方法进行配置。换句话说，配置是通过Scala代码完成的。这对于具有简短配置的项目以及进行配置的人员可以轻松编辑Scala而言是完美的。

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

4. 文献资料

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

   由于Spring的文档已经井井有条，而且易于查找，因此我将回顾为Lift找到的文档。Lift文档基本上有4个来源：LiftWeb Book，API Docs，LiftWeb的Google组和“ 入门 ”。也有一套不错的代码示例，但我不会将它们本身称为“文档”。

   API文档不完整。LiftWeb书籍已在树木上出版，但也可以在线免费获得。它确实很有用，尽管其明确的教学风格有时会激怒我。教程很长，合同很短。Spring有适当的手册，Lift缺少。

   但是Lift确实有很多很好的例子。如果您愿意阅读Lift代码和示例代码（并且已经非常了解Scala），则可以在很短的时间内完成工作。

这两个框架都很引人注目。您可以选择各种各样的应用程序，并做得很好。

我必须说我非常不同意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或基本上，提升Web框架不依赖于如何将对象具体化为会话。此外，会话和请求周期是开放的，使得将事务挂钩插入请求/响应周期很简单。
• Lift的理念是“服务器团队需要一种语言，而不是多种语言。” 这意味着配置是通过Scala完成的。这意味着我们不必使用XML语法实现40％的Java语言构造来创建灵活的配置选项。这意味着编译器语法和类型检查配置数据，因此您在运行时不会得到任何奇怪的XML解析或不正确的数据。这意味着您不必具有基于所使用的库来了解所使用注释的详细信息的IDE。
• 是的，Lift的文档并不是它的强项。

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

在开始编写Lift之前，我写了Web Framework Manifesto。与我所知的任何其他Web框架相比，Lift在很大程度上和达到的目标都可以满足这些目标。

Lift的核心是寻求抽象HTTP请求/响应周期，而不是围绕HTTP Request放置对象包装。在实践上，这意味着用户可以执行的大多数操作（提交表单元素，执行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-> Function association已被证明非常耐用...相同的构造适用于普通形式，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，甚至应用访问控制检查（当前会话或请求是否有权访问给定的用户记录）。因此，当User实例到达应用程序逻辑时，它已经过审查。

有了这两个核心部分，Lift在安全性方面具有巨大优势。为了给您一个提升Lift安全性的想法，而不会影响功能，Rasmus Lerdorg为Yahoo!做了安全性。关于FourSquare（Lift海报子站点之一）的说法如下：

@foursquare上的四星-一段时间以来，我很高兴看到第一个站点没有一个安全问题（我可以找到）-http: //twitter.com/rasmus/status/5929904263

当时，FourSquare的代码由一位工程师负责（不是@harryh不是超级天才），他的主要工作是重新编写PHP版本的FourSquare，同时应对每周的流量增加一倍。

Lift的安全重点的最后一部分是SiteMap。它是一个统一的访问控制，站点导航和菜单系统。开发人员使用Scala代码（例如If(User.loggedIn _)或If(User.superUser _)）定义每个页面的访问控制规则，并在开始任何页面渲染之前应用这些访问控制规则。这与Spring Security非常相似，不同之处在于它是从项目开始时就引入的，并且访问控制规则与应用程序的其余部分统一在一起，因此当URL出现时，您不必具有更新XML中的安全规则的过程。更改或计算访问控制更改的方法。

到目前为止，Lift的设计理念为您带来了访问控制方面的优势，抵御OWASP十大安全漏洞，比Spring更好的Ajax支持和更高的开发人员生产力。

但是，Lift还为您提供了所有Web框架中最好的Comet支持。这就是为什么Novell选择Lift为他们的Pulse产品提供动力的原因，这就是Novell 对Lift的评价：

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

因此，Lift不仅是另一个我的MVC框架。这个框架背后有一些核心设计原则，它们已经非常成熟。这个框架提供了安全性和开发人员生产率的双重优势。Lift是一个分层构建的框架，可根据开发人员的需求为开发人员提供正确的选择……用于视图生成的选择，用于持久性的选择等。

Scala和Lift给开发人员提供了比构成Spring的XML，注释和其他惯用语言更好的体验。

我建议您检查一下play框架，它有一些非常有趣的想法，并支持Java和Scala中的开发

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

我强烈考虑在最近的Web项目中使用Lift，而不是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一直稳定可靠，并且使用起来非常容易。

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

扩展您的知识总是值得的：)我刚刚开始学习Scala，这影响了我编写普通Java的方式，并且可以说到目前为止，它非常有益。

我讨厌把你的世界彻底抛弃。但是您可以在一个应用程序中使用Scala，Java，Lift，Spring，并且没有问题。

以我的拙见，想像才是最重要的。

让我们考虑您要编写一个应用程序。如果您是一位体面的开发人员，则应该已经在脑中构建了该应用。下一步是通过代码发现其工作方式。为此，您需要通过将虚构的应用程序转换为将其转换为真实应用程序的函数。该功能是一种编程语言。所以

Real app = programming language (imagined app)

因此，语言选择很重要。框架也是如此。这里有很多聪明的人会为您提供选择方面的建议，但最终，最能体现您的想象力的语言/框架应该是您的选择。因此，两者都具有原型，可以做出选择。

对于我来说，我正在慢慢学习Scala和Lift，并热爱它。

但是主要的问题是我们无法将弹簧与升力进行比较。Lift基本上用作UI框架，Spring用作DI框架。
如果您要开发的Web应用程序具有大量后端，请确保可以使用lift。
但是，如果您正在开发的Web应用程序具有一些系列后端，并且您定义了该代码，则需要跳到春天。