如何解决为什么在Java / Spring上使用Scala / Lift？
假设我们对Scala和Java同样满意，并忽略（巨大的）语言差异，除非它们与Spring或Lift有关。
在成熟度和目标方面，Spring和Lift几乎完全相反。
- Spring比Lift大五岁
- 提升是整体的，仅针对网页；Spring是模块化的，同时针对Web和“常规”应用程序
- Spring支持大量的Java EE功能。电梯无视那东西 一句话，Spring是重量级的，Lift是轻量级的。有了足够的决心和资源，你就可以轻而易举地做到这一点，但是你同时需要很多。
在使用这两个框架之后，我想到的是具体的差异。这不是一个详尽的列表，无论如何我都无法编译。对我来说最有趣的事情就是…
- View philosophy
提升鼓励在片段/动作方法中放置一些视图素材。片段代码特别是将以编程方式生成的表单元素<div>s，<p>s等等。
这功能强大且有用，特别是因为Scala具有内置的语言级XML模式。可以在Scala方法中内联编写XML，包括括号中的变量绑定。对于非常简单的XML服务或服务模型，这可能很令人愉悦-你可以将一个HTTP响应操作套件全部打包在一个简洁的文件中，而无需模板或进行大量的配置。缺点是复杂性。根据你走的远近，视图和逻辑之间的关注点模糊分离，或者没有分离。
相比之下，针对Web应用程序的Spring常规使用会在视图与其他所有内容之间形成强烈的分隔。我认为Spring支持多个模板引擎，但是我只在严重的情况下使用过JSP。用JSP进行Lift启发的“模糊MVC”设计会很疯狂。在大型项目中，这是一件好事，在这里，阅读和理解的时间可能会很充沛。
- Object-Relational Mapper Choices
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组件转换出来。
- Configuration
提升应用几乎完全通过应用范围的“启动”类的方法进行配置。换句话说，配置是通过Scala代码完成的。这对于具有简短配置的项目以及进行配置的人员可以轻松编辑Scala而言非常理想。
Spring在配置方面相当灵活。可以通过XML配置或注释来驱动许多conf选项。
- Documentation
Lift的文档还很年轻。Spring的文档非常成熟。没有比赛。
由于Spring的文档已经井井有条，而且易于查找，因此我将回顾为Lift找到的文档。Lift文档基本上有4个来源：LiftWeb Book，API Docs，LiftWeb的Google组和“ 入门 ”。也有一套不错的代码示例，但是我不会将它们本身称为“文档”。
API文档不完整。LiftWeb书籍已在树木上出版，但也可以在线免费获得。它确实很有用，尽管其明确的教学风格有时会激怒我。教程很长，合同很短。Spring有适当的手册，Lift缺少。
但是Lift确实有很多很好的例子。如果你愿意阅读Lift代码和示例代码（并且已经非常了解Scala），则可以在很短的时间内完成工作。
这两个框架都很引人注目。你可以选择各种各样的应用程序，并做得很好。
它由离散元素组成。它不会忽略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进行重放攻击和进行许多参数篡改攻击比包括Spring在内的大多数其他Web框架要困难得多。这也意味着开发人员生产率更高，因为他们专注于用户操作和与用户操作相关联的业务逻辑，而不是打包和解包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，彗星，多页向导等。
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是一个分层构建的框架，可根据开发人员的需求为开发人员提供正确的选择……用于视图生成的选择，用于持久性的选择等。
与构成Spring的XML，注释和其他惯用语言的混合物相比，Scala和Lift给开发人员提供了更好的体验。
解决方法
我知道这个问题有点悬而未决，但是我一直在将Scala / Lift视为Java / Spring的替代方案，我想知道Scala / Lift在此之上的真正优势是什么。从我的观点和经验来看，Java Annotations和Spring确实最小化了您为应用程序要做的编码量。Scala / Lift是否会对此有所改善？