假设我们对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),则可以在很短的时间内完成工作。
这两个框架都很引人注目。你可以选择各种各样的应用程序,并做得很好。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)