为什么在Java / Spring上使用Scala / Lift？

Question

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

Answer 1

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

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

• Spring比Lift大五岁
• 提升是整体的，仅针对网页；Spring是模块化的，同时针对Web和“常规”应用程序
• Spring支持大量的Java EE功能。电梯无视那东西
  一句话，Spring是重量级的，Lift是轻量级的。有了足够的决心和资源，你就可以轻而易举地做到这一点，但是你同时需要很多。
  

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

1. View philosophy

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

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

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

1. 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组件转换出来。

1. Configuration

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

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

1. Documentation

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

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

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

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

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