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

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

就成熟度和目标而言,Spring和Lift几乎截然相反。

• 春天比春天早五年
• Lift是单片的,只针对web;Spring是模块化的,面向web和“常规”应用程序
• Spring支持大量javaee特性;电梯忽略了那些东西

一言以蔽之,弹簧重,升力轻。有了足够的决心和资源,你就可以扭转这种局面,但你需要一个

1. 观哲学

   <div> 是的, <p> s、 等等。

   这是非常强大和有用的,特别是因为Scala有一个内置的语言级XML模式。可以在Scala方法中内联编写XML,包括大括号中的变量绑定。对于非常简单的XML服务或服务模型来说,这是令人愉快的—您可以在一个非常简洁的文件中完成一组HTTP响应操作,而无需模板或大量辅助配置。缺点是复杂性。取决于你走了多远,视图和逻辑之间的关注点有模糊的分离,或者没有分离。

   相比之下,定期使用Spring for webapps会在视图和其他所有内容之间强制执行一个很强的分离。我认为Spring支持几个模板引擎,但我只在一些重要的方面使用了JSP。用JSP做一个灵感来源于Lift的“fuzzy MVC”设计简直是疯了。对于大型项目来说,这是一件好事,因为在这些项目中,仅仅阅读和理解的时间可能会非常多。

2. 对象关系映射器选择

   电梯的内置ORM是“Mapper”。有一个新的选择叫做“记录”,但我认为它仍然被认为是阿尔法之前。LiftWeb的书中有关于使用Mapper和JPA的部分。

   电梯 CRUDify

   当然,弹簧支持 panoply of standard and/or mature database technologies

3. 配置

   Lift应用程序几乎完全是通过一个方法来配置的,一个应用程序范围的“Boot”类。换句话说,配置是通过Scala代码完成的。这非常适合于配置简单的项目,当进行配置的人能够轻松地编辑Scala时。

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

4. 既然Spring的文档已经组织得很好,而且很容易找到,我将回顾一下我为Lift找到的文档。基本上有4个电梯文件来源:电梯 LiftWeb Book ,的 API Docs ,电梯 Google group ,和“ Getting Started ". 这里还有一套很好的代码示例,但我不会把它们本身称为“文档”。

   API文档不完整。LiftWeb的书已经在树上出版了,但也可以在网上免费获得。它真的很有用,尽管它明确的说教风格有时会激怒我。辅导有点长,合同有点短。弹簧有一个合适的手册,而升降机缺少。

   但Lift确实有一组很好的例子。如果您能够轻松地阅读Lift代码和示例代码(而且您已经非常了解Scala),那么您可以在很短的时间内解决问题。

这两个框架都令人信服。有一个广泛的应用程序,你可以选择其中之一,并做好。

电梯不是铁板一块的。它是由离散元素组成的。它不忽略J/EE元素,它支持JNDI、JTA、JPA等。事实上,您不必使用J/EE的这些元素,这是Lift模块化设计的有力标志。

• Lift的视图哲学是“由开发人员决定”。Lift提供了一种模板机制,不允许在视图中使用任何逻辑代码,一种基于执行Scala代码和Scala的XML文本的视图机制,以及一种基于 Scalate
• Lift的对象持久性哲学是“由开发人员决定”。Lift有一个Mapper,它是一个ActiveRecord样式的对象关系映射器。它完成了小项目的工作。提升支架JPA。Lift有一个记录抽象,它支持对象进出关系数据库,进出NoSQL存储(Lift包括对CouchDB和MongoDB的本机支持,但是适配器层只有几百行代码,所以如果您想要Cassandra或其他东西,获得它不需要很多工作),Web框架不依赖于对象如何具体化到会话中。此外,会话和请求周期是开放的,因此将事务挂钩插入请求/响应周期是简单的。
• Lift的理念是“服务器团队需要知道一种语言,而不是多种语言”,这意味着配置是通过Scala完成的。这意味着我们不必用XML语法实现40%的Java语言结构来创建灵活的配置选项。这意味着编译器语法和类型会检查配置数据,这样在运行时就不会得到任何奇怪的XML解析或不正确的数据。In意味着您不必有ide来理解您正在使用的基于您正在使用的库的注释的细节。
• 是的,电梯的文件不是它的强项。

我写道 Web Framework Manifesto 在我开始写作之前。在很大程度上,而且比我所知道的任何其他web框架都更大的程度上,Lift实现了这些目标。

Lift的核心是抽象出HTTP请求/响应周期,而不是在HTTP请求周围放置对象包装器。在实际层面上,这意味着用户可以执行的大多数操作(提交表单元素、执行Ajax等)都由浏览器中的GUID和服务器上的函数表示。当GUID作为HTTP请求的一部分显示时,将使用提供的参数应用(调用)该函数。由于guid很难预测,并且是特定于会话的,因此使用Lift进行重放攻击和许多参数篡改攻击要比大多数其他web框架(包括Spring)困难得多。这也意味着开发人员的工作效率更高,因为他们关注的是用户操作和与用户操作相关的业务逻辑,而不是打包和解包HTTP请求的管道。例如,接受或拒绝FourSquare好友请求的代码:

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、comet、多页向导等。

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

使用Scala的内置模式匹配,我们匹配传入的请求,提取路径的第三部分并获取与该值对应的用户,甚至应用访问控制检查(当前会话或请求是否有权访问给定的用户记录)。所以,当用户实例点击应用程序逻辑时,它就被审查了。

Rasmus Lerdorg 谁为雅虎做了安全工作!关于FourSquare(电梯海报儿童网站之一):

四颗星到@foursquare-1st网站在一段时间内,我已经采取了一个很好的看,没有一个安全问题(我可以找到)-- http://twitter.com/rasmus/status/5929904263

当时,FourSquare有一位工程师在编写代码(并不是说@harryh不是一个超级天才),他的主要精力是重新编写FourSquare的PHP版本,同时应对每周流量翻倍的问题。

If(User.loggedIn _) 或 If(User.superUser _) )并且在任何页面呈现开始之前应用这些访问控制规则。这与Spring安全性非常相似,不同的是它是从项目开始时就被嵌入的,并且访问控制规则与应用程序的其余部分是统一的,因此当url更改或计算访问控制的方法更改时,您不必有更新XML安全规则的过程。

到目前为止,Lift的设计理念为您提供了baked-in访问控制、抵抗OWASP十大安全漏洞、更好的Ajax支持以及比Spring更高的开发人员生产率等好处。

但是Lift也为您提供了最好的Comet支持。这就是为什么诺维尔选择电梯来为他们提供动力 Pulse product

Lift是一种 使您作为开发人员能够 专注于大局。 有力、富有表现力的打字和 更高级的功能,如 内置的Comet支持允许您 注重创新,而不是 管道工程。构建一个丰富的、实时的 像Novell Pulse这样的web应用程序 从盖子下面提起。

所以,Lift不仅仅是另一个metoomvc框架。这是一个框架,其背后有一些已经非常成熟的核心设计原则。这个框架提供了安全性和开发人员生产力的双重优势。Lift是一个分层构建的框架,它根据开发者的需求为开发者提供了正确的选择。。。视图生成选项、持久性选项等。

Scala和Lift为开发人员提供了比XML、注释和其他组成Spring的习惯用法的混合体更好的体验。

只是为了好玩。为了学习新的编程方法。

在最近的一个web项目中,我强烈希望使用Lift,而不是SpringMVC的忠实粉丝。我没有使用最新的版本,但是springmvc的早期版本让您在运行web应用程序时经历了很多困难。我几乎卖电梯,直到我看到电梯可以非常会话依赖,将需要'粘性会话'正常工作。摘自 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的方式,我可以说到目前为止它非常有益。

Real app = programming language (imagined app)

所以语言的选择很重要。框架也是如此。这里有很多聪明人会建议你选择什么,但最终,最能翻译你想象力的语言/框架应该是你的选择。所以你可以选择两者。

对我来说,我正在慢慢地学习Scala,并且喜欢它。

如果你正在开发的web应用程序确实有那么多的后端,请确定你可以使用lift。