为什么我会使用Scala / Lift而不是Java / Spring？ [英] Why would I use Scala/Lift over Java/Spring?
问题描述
我知道这个问题有点开放，但我一直在考虑使用Scala / Lift作为Java / Spring的替代品，我想知道Scala / Lift对它有什么真正的优势。从我的观点和经验来看，Java Annotations和Spring确实最大限度地减少了您必须为应用程序执行的编码量。 Scala / Lift会改进吗？
I know this question is a bit open but I have been looking at Scala/Lift as an alternative to Java/Spring and I wonder what are the real advantages that Scala/Lift has over it. From my perspective and experience, Java Annotations and Spring really minimizes the amount of coding that you have to do for an application. Does Scala/Lift improve upon that?
推荐答案
让我们假设我们在Scala和Java中同样适应，并忽略（巨大的）语言差异除了属于Spring或Lift之外。
Spring和Lift在成熟度和目标方面几乎完全相反。
Spring and Lift are almost diametrically opposed in terms of maturity and goals.
- 春天大约比电梯大五岁
- 电梯是单片的，只针对网络; Spring是模块化的，针对web和常规应用程序
- Spring支持大量的Java EE功能; Lift忽略那些东西
在一句话中，Spring是重量级的，而Lift是轻量级的。有足够的决心和资源，你可以把它转过来，但是你需要一个很多。
In a sentence, Spring is heavyweight and Lift is lightweight. With sufficient determination and resources you can turn that on its head, but you would need a lot of both.
这里有一些具体的差异在使用这两个框架后，在我的脑海里。这不是一个详尽的列表，无论如何我都无法编译。对我来说最有趣的是......
Here are concrete differences that stuck in my mind after working with both frameworks. This isn't an exhaustive list, which I can't compile anyhow. Just what seemed most interesting to me...
-
查看理念
View philosophy
Lift鼓励将一些视图材料放在片段/动作方法中。片段代码尤其会以编程方式生成的表单元素，< div> s，< p> s，等等。
Lift encourages placing some view material in snippet/action methods. Snippet code especially will be sprinkled with programmatically generated form elements, <div>s, <p>s, etc.
这是强大而有用的，特别是因为Scala具有内置语言级XML模式。可以在Scala方法中内联编写XML，包括大括号中的变量绑定。对于非常简单的XML服务或服务模型，这可能是令人愉快的 - 您可以在一个精彩简洁的文件中敲出一套HTTP响应操作，无需模板或许多附带配置。缺点是复杂性。根据你走了多远，视图和逻辑之间存在模糊的关注分离，或者没有分离。
This is powerful and useful, especially since Scala has a builtin language-level XML mode. One can write XML inline within Scala methods, including variable bindings in braces. This can be delightful for very simple XML services or mockups of services -- you can bang out a suite of HTTP response actions all in one splendidly terse file, without templates or much attendant configuration. The downside is complexity. Depending on how far you go, there's either a fuzzy separation of concerns between view and logic, or no separation.
相比之下，定期使用Spring进行webapps强制执行视图与其他一切之间的分离。我认为Spring支持几种模板引擎，但我只使用JSP来处理任何严重问题。用JSP做一个以Lift为灵感的模糊MVC设计将是疯狂的。这对于大型项目来说是件好事，在这些项目中，阅读和理解的时间可能非常大。
In contrast, regular use of Spring for webapps enforces a strong separation between the view and everything else. I think Spring supports several templating engines, but I've only used JSP in anything serious. Doing a Lift-inspired "fuzzy MVC" design with JSP would be madness. This is a good thing on larger projects, where the time to just read and understand can be overwhelming.
对象关系映射器选择
Lift的内置ORM是Mapper。有一个名为Record的即将推出的替代品，但我认为它仍然被认为是pre-alpha。 LiftWeb Book中有关于使用Mapper和JPA的部分。
Lift's builtin ORM is "Mapper". There's an upcoming alternative called "Record", but I think it's still considered pre-alpha. The LiftWeb Book has sections on using both Mapper and JPA.
Lift的 CRUDify 功能，很酷，只适用于Mapper（而不是JPA）。
Lift's CRUDify feature, cool as it is, only works with Mapper (and not JPA).
当然，Spring支持 panoply标准和/或成熟的数据库技术。有效的词是支持。从理论上讲，您可以使用任何带有Lift的Java ORM，因为您可以从Scala调用任意Java代码。但是Lift只支持Mapper和（在较小程度上）JPA。此外，在Scala中使用非平凡的Java代码目前并不像人们想象的那样无缝;使用Java ORM，您可能会发现自己在任何地方都使用Java和Scala集合，或者将所有集合转换为Java组件。
Of course, Spring supports a panoply of standard and/or mature database technologies. The operative word there is "supports". Theoretically, you can use any Java ORM with Lift, since you can call arbitrary Java code from Scala. But Lift only really supports Mapper and (to a much lesser extent) JPA. Also, working with nontrivial Java code in Scala is currently not as seamless as one might like; using a Java ORM, you will probably find yourself either using both Java and Scala collections everywhere or converting all collections in and out of the Java components.
配置
提升应用程序几乎完全通过应用程序范围的Boot类方法进行配置。换句话说，配置是通过Scala代码完成的。这对于具有简短配置的项目非常适合，并且当进行配置的人习惯编辑Scala时。
Lift apps are configured pretty much entirely through a method an application-wide "Boot" class. In other words, the config is done through Scala code. This is perfect for projects with brief configurations, and when the person doing the configuring is comfortable editing Scala.
Spring在配置方面非常灵活。可以通过XML配置或注释来驱动许多conf选项。
Spring is pretty flexible in terms of configuration. Lots of conf options can be driven either through XML configuration or annotations.
文档
Lift的文档很年轻Spring的文档非常成熟。没有比赛。
Lift's documentation is young. Spring's docs are pretty mature. There's no contest.
由于Spring的文档已经很好地组织并且很容易找到，我将查看我为Lift找到的文档。 Lift文档基本上有4个来源： LiftWeb Book ， API文档，LiftWeb的 Google小组和使用入门。还有一套很好的代码示例，但我本身并不称它们为文档。
Since Spring's docs are already nicely organized and easy to find, I'll review the docs I found for Lift. There are basically 4 sources of Lift documentation: the LiftWeb Book, the API Docs, LiftWeb's Google group, and "Getting Started". There's also a nice suite of code examples, but I wouldn't call them "documentation" per se.
API文档不完整。 LiftWeb Book已在树上发布，但也可以在线免费获取。这真的很有用，虽然它的确定的教学风格有时让我恼火。在教程和合同短缺上有点长。 Spring有一个适当的手册，Lift缺乏。
The API docs are incomplete. The LiftWeb Book has been published on trees, but it's also freely available online. It is really useful, although its decidedly didactic style irritated me at times. It's a little long on tutorial and short on contract. Spring has a proper manual, which Lift lacks.
但是Lift确实有一套很好的例子。如果您习惯阅读Lift代码和示例代码（并且您已经熟悉Scala），那么您可以在相当短的时间内完成工作。
But Lift does have a nice set of examples. If you're comfortable reading the Lift code and example code (and you know Scala well already), you can work things out in fairly short order.
两个框架都很引人注目。有广泛的应用程序，您可以选择并做得很好。
Both frameworks are compelling. There's a broad range of apps where you can choose either and do well.
这篇关于为什么我会使用Scala / Lift而不是Java / Spring？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
