为什么我会使用Scala/Lift而不是Java/Spring？

我知道这个问题有点开放,但我一直在考虑使用Scala/Lift作为Java/Spring的替代品,我想知道Scala/Lift对它有什么真正的优势.从我的观点和经验来看,Java Annotations和Spring确实最大限度地减少了您为应用程序所做的编码量.Scala/Lift会改进吗？

1> David Pollak..：

---

我必须说我非常不同意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.在很大程度上,比我所知道的任何其他网络框架更大程度上,Lift满足了这些目标.

提升核心旨在抽象出HTTP请求/响应周期,而不是在HTTP请求周围放置对象包装器.在实际层面,这意味着用户可以采取的大多数操作(提交表单元素,执行Ajax等)由浏览器中的GUID和服务器上的函数表示.当GUID作为HTTP请求的一部分呈现时,将使用提供的参数应用(调用)该函数.由于GUID难以预测且特定于会话,因此与大多数其他Web框架(包括Spring)相比,Lift更难以重放攻击和许多参数篡改攻击.这也意味着开发人员的工作效率更高,因为他们专注于用户操作和与用户操作相关的业务逻辑,而不是打包和解包HTTP请求的管道.

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", }) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", })

就这么简单.因为在创建函数时,friendRequest在范围内,所以函数会关闭范围...不需要公开朋友请求的主键或执行任何其他操作...只需定义按钮的文本(它可以本地化,也可以从XHTML模板中提取,也可以从本地化模板中提取)以及按下按钮时执行的功能.Lift负责分配GUID,设置Ajax调用(通过jQuery或YUI,是的,您可以添加自己喜欢的JavaScript库),使用后退进行自动重试,通过排队Ajax请求来避免连接不足等.

因此,Lift和Spring之间的一个重要区别是,Lift的GUID与功能相关的理念具有更好的安全性和更好的开发人员生产力的双重好处.GUID - > Function关联已被证明非常耐用......相同的构造适用于普通形式,ajax,彗星,多页面向导等.

Lift的下一个核心部分是尽可能长时间保持高水平的抽象.在页面生成方面,这意味着将页面构建为XHTML元素,并将页面保持为XHTML,直到流式传输响应之前.这样做的好处是可以抵抗跨站点脚本错误,在编写页面后将CSS标记移动到头部和脚本到页面底部的能力,以及基于目标浏览器重写页面的能力.在输入端,可以重写URL以便以类型安全的方式提取参数(查询和路径参数),高级别的安全检查数据可在请求周期的早期进行处理.例如,以下是如何定义REST请求的服务:

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => {user.name}
    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十大安全漏洞的抵制,更好的Ajax支持以及比Spring更高的开发人员生产力的好处.

但是Lift还为您提供了所有Web框架的最佳Comet支持.这就是为什么Novell选择Lift来为他们的Pulse产品供电,这就是Novell对Lift的看法:

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

所以,Lift不仅仅是另一个我的MVC框架.它是一个框架,它背后有一些核心设计原则已经成熟得很好.它是一个框架,具有安全性和开发人员生产力的双重优势.Lift是一个层次构建的框架,可以根据用户的需求为开发人员提供正确的选择...视图生成选择,持久性选择等.

Scala和Lift为开发人员提供了比构成Spring的XML,注释和其他习惯用语更好的体验.

---

自90年代中期以来,我一直在编写webapps.我使用过Perl,Java,Seam,JSP和其他一大堆.我认识的每个人都使用spring抱怨了配置和依赖性的困难,maven噩梦等等.几个星期前我开始在一个项目上使用Lift,我非常惊讶.这是我用过的第一个框架(和语言),几乎没有任何工作.到目前为止,我已经在我的应用程序中编写了许多功能,并且我不断惊讶于我能够多快地做到这一点......即使是使用sucky docs和对Scala的有限理解.眼见为实.

---

@HoàngLong有很多方法可以解决软件演化的难度.我只是陈述我的经验:Java正在展示它作为一种语言的时代,以及构建在它上面的框架.是时候发展到更具表现力和强大力量的事物,而不是所有的样板和配置疯狂.

---

blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html的存档版本可在http://replay.web.archive.org/20070220231839/http://blog.lostlake上找到. .ORG /的index.php？/archives/16-Web-Framework-Manifesto.html

2> Dan LaRocque..：

---

让我们假设我们在Scala和Java中同样适应,并忽略(巨大的)语言差异,除了它们属于Spring或Lift.

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

春天比Lift大五岁

电梯是整体的,只针对网络; Spring是模块化的,针对Web和"常规"应用程序

Spring支持大量Java EE功能; 电梯忽略那些东西

在一句话中,Spring是重量级的,而Lift是轻量级的.有足够的决心和资源,你可以把它转过来,但你需要很多.

以下是在使用这两个框架后陷入困境的具体差异.这不是一个详尽的列表,无论如何我都无法编译.对我来说最有趣的是......

观点哲学

Lift鼓励将一些视图材料放在片段/动作方法中.片段代码特别是将以编程方式生成的表单元素,

s,

s等.

这是强大而有用的,特别是因为Scala具有内置语言级XML模式.可以在Scala方法中内联编写XML,包括大括号中的变量绑定.对于非常简单的XML服务或服务模型,这可能是令人愉快的 - 您可以在一个精彩简洁的文件中敲出一套HTTP响应操作,无需模板或许多附带配置.缺点是复杂性.根据您的距离,视图和逻辑之间的关注模糊分离,或者没有分离.

相比之下,定期使用Spring进行webapps会强制实现视图与其他所有内容之间的强烈分离.我认为Spring支持几种模板引擎,但我只使用JSP来处理任何严重问题.用JSP做一个以Lift为灵感的"模糊MVC"设计将是疯狂的.这对于大型项目来说是件好事,在这些项目中,阅读和理解的时间可能非常大.

对象关系映射器选择

Lift的内置ORM是"Mapper".有一个名为"Record"的即将推出的替代品,但我认为它仍然被认为是pre-alpha.LiftWeb Book中有关于使用Mapper和JPA的部分.

Lift的CRUDify功能很酷,只适用于Mapper(而不是JPA).

当然,Spring支持一整套标准和/或成熟的数据库技术.有效的词是"支持".从理论上讲,您可以将任何Java ORM与Lift一起使用,因为您可以从Scala调用任意Java代码.但是Lift只支持Mapper和(在较小程度上)JPA.此外,在Scala中使用非平凡的Java代码目前并不像人们想象的那样无缝; 使用Java ORM,您可能会发现自己要么在任何地方使用Java和Scala集合,要么将所有集合转换为Java组件.

组态

Lift应用程序几乎完全通过应用程序范围的"Boot"类方法进行配置.换句话说,配置是通过Scala代码完成的.这对于具有简短配置的项目非常适合,并且在进行配置的人员可以轻松编辑Scala时.

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

文档

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

由于Spring的文档组织良好且易于查找,因此我将查看我为Lift找到的文档.Lift文档基本上有4个来源:LiftWeb Book,API Docs,LiftWeb的Google小组和" 入门 ".还有一套很好的代码示例,但我本身并不称它们为"文档".

API文档不完整.LiftWeb Book已在树上发布,但也可以在线免费获取.这真的很有用,虽然它的确定的教学风格有时让我感到恼火.这有点长的教程和合同的短缺.Spring有一本适当的手册,Lift没有.

但是Lift确实有一套很好的例子.如果您习惯阅读Lift代码和示例代码(并且您已经熟悉Scala),那么您可以在相当短的时间内完成工作.

这两个框架都很引人注目.有广泛的应用程序,您可以选择并做得很好.

---

一个很好的答案,我不同意的一点是:春天是重量级的.它拥有广泛的优秀APIS,并强加了必要的结构工作方式以获得良好的结果,但与最初取代它的J2EE东西相比,它是一个更轻量级的解决方案.当然,"轻量级"在旁观者眼中,所以这绝对是一个主观论点.那么我的2美分.

---

好的答案,非常客观.电梯做了太多看似聪明的东西,非常愚蠢.将页面逻辑移动到后端,将HTML混合到scala代码,这比页面模板中的控件标记更糟糕.我不知道他们为什么这样做,也许他们认为Scala必须快速处理XML."电梯权威指南"是我读过的最糟糕的技术书籍.

3> 小智..：

---

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

---

我查了一下Play.我没有看到除了内置类重新加载以推荐它之外的任何东西,并且使用免费的Scala JRebel许可证,你可以通过Lift得到它.

4> Roman..：

---

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

5> mguymon..：

---

我强烈期待将Lift用于最近的一个Web项目,而不是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一直稳定可靠,非常容易使用.

6> pr1001..：

---

我没有从Java背景来到Lift和Scala,所以这不是来自个人经验,但我知道许多Lift开发人员发现Scala是一种比Java更简洁高效的语言.