Java Web开发框架对比—Part2—框架复杂性

Web框架有点像酸酵母,你要么喜欢它,要么讨厌它!什么?你从来没听过什么是酸酵母?没关系,那么你很有可能会讨厌它!使自己沉浸在一个新型语言中或者一个项目里,快速拥有高效生产力是十分重要的。学习一个Web框架也同样如此。

这一部分将会比较和对比每个Web框架的类别排序(总分为5分),并从下面几个方面给出我们的评价:

  1. 快速原型
  2. 框架复杂性
  3. 易于使用性
  4. 文档与社区

框架复杂性

本节,我们将逐个探讨框架的构建。这里我们将讨论每种框架内存在多少可移动部件,以及框架的复杂性给开发带来的影响。你真的想学习10种技术后再使用某个框架?当然,在选择框架的时候还有其他的考虑因素,比如,对于您设计的应用的程序是否收获的额外功能和效益大于复杂度带来的代价?所以,请记住一句老话:“开发时选择用什么(框架),就需要在产品中支持(它们)!”

Spring MVC

Spring是所有框架当中的珠穆朗玛峰。基本的Spring框架提供了超过22个子框架,它可以随着你的应用程序的范围增加而增加。这些成熟的项目涵盖了从基本而又全面实用的MVC模式,到Spring.NET和Spring用于Android App的开发。

Spring MVC的架构比较简单,但还是有很多需要注意的地方。以及如果出现了错误,一些抽象的功能非常难于调试。Spring高度依赖于Spring核心(Spring Core)。

得分:3.5/5 — Spring吓跑了一些新手和一些喜欢 简单、轻量级框架的开发者。它虽然略显沧桑,但却是一个提供了多种方式进行扩充和配置的成熟框架——这中特性让Spring变得非常复杂。

Grails

Grails的MVC的功能Spring MVC都有支持;GORM(Grails的对象关系映射)实际上以Hibernate表现(facade)。这一切都与核心的Spring框架密不可分。所有这些框架都是成熟的框架,但是重量级框架与Grails在顶层进行了抽象。Grails同样尝试着通过拥有自己的控制台、构建工具和丰富的插件成为“一站式”框架。但是当碰到一些难以调试的问题时,这一切都会让情况变得很复杂。

得分:3.5/5 — Grails拥有所有Spring和Hibernate框架有的复杂性能,并在此之上增加了抽象层。

译 注:full-stack 的设计意味着各层能够无缝的集成在一起,并且遵循DRY原则”Don’t Repeat  Yourself”。通过将各层共用的东西抽取出来,通过自顶向下的设计无缝集成、粘合在一起,达到更高层次、更粗粒度的重用。与此同时,为了保证灵活的 可 扩展性,在更高、更粗的粒度上遵守开放—封闭(Open-Close)的原则,在各层的各个关键点,要提供诸多的钩子、回调的接口以及供扩展。full- stack的设计,在 层与层之间并不一味地追求松散的机制。相反,在层与层之间增强一定的内聚性、粘合力,以此来达到粗粒度的封装与重用。

Vaadin

目前Vaadin框架是建立在GWT基础上(稍作改变),是一个成熟的框架。开发一个Vaadin项目的方式类似于在GWT框架中创建一个层次化的组件结构。尽管如此,但是学会GWT框架并不是熟练使用Vaadin的必要条件。

得分:4/5 — Vaadin比起GWT框架稍显复杂,因为它嵌入了一个GWT版本,这里不作过多评价。

GWT

如果在你看来小型框架非常容易使用的话,那么GWT则是一个相当复杂的框架。你只需要关注Java代码以及组件所处的位置(或者使用拖拽方式让GWT自动生成所有代码),GWT交叉编译器就可以生成支持流浏览器、高度优化的JavaScript代码。

得分:4/5  — 虽然无论是直接编码或是拖拽控件进行设计,GWT这都是一个非常复杂的框架,但通过这个框架可以简化你的开发和执行过程。

Wicket

作为一个MVC模式,Wicket框架可以说非常简单明。它有清晰HTML文本、大量组件库以及存在可用于检索、推送数据的组件模型对象。但是,模型的继承机制可能相当难以把握,尽管它增加了代码的重用性,但是却降低了代码的可读性。而且这种复杂性也不是必须的。

得分:2.5/5 — 框架简单明了,但继承机制包含了一个不必要的复杂模型。虽然很实用,但也很难把握。

Play

Play是一个相当复杂的框架,有很多闪光点。这也是为什么Play框架营造了一个如此强大的生态系统。Play框架提供了Netty、SBT、Akka以及一个Scala模板引擎,并且内建了几个其他模块。Play框架着重强调了约定编程,所以这个框架负责整合模块之间的契合性和配置。这就让开发者很少有措手不及的情景。

得分:2/5 — Play框架营造了一个完整的生态系统,它并不仅仅只是一个框架,更提供了很多有益的性能。但在此之前需要掌握一些Scala知识,所以增加了额外的困难。

Struts

Struts并非是轻量级的框架,但是也不是过于复杂。当用户使用到Struts框架时,会有一个Action(Struts中的控制器的术语)被执行,而其中的拦截器也会在前后被调用。拦截器可以管理日志、安全性能以及双提交问题等。官方文档指出:“默认拦截器的堆栈旨在满足大部分应用程序的需求,不同部分应用程序不需要额外添加拦截器或者变更拦截器堆栈”。这是使用选定视图所呈现出来的结果,也是魔力所在。

得分:4/5 — Struts是一个有着单纯MVC模式的简单框架,没有额外组件增加它的难度。

JSF

JSF及其复杂,这是该框架最大的问题。然而,这不是JSF的错,这是由于Java EE的规范和运行时的不变性造成的。JSF规范允许使用非Java EE容器,比如Tomcat,使用开放源码代码实现。这极大地降低了使用Java企业应用服务器的复杂性(还有新的轻量级应用服务器——WebSphere Liberty Profile作为中间力量)。然而在享受访问Java EE堆栈好处的同时总是会带来复杂性的增加。

在Java EE堆栈中使用JSF框架得分:3.5/5 — 当使用Java EE实现JSF时,我们必须考虑到Java EE规范以及运行一个完整的Java EE服务器的复杂性,很少有人声称Java EE的规范是不复杂的。

在操作系统中实现使用JSF框架得分:3/5 — 当使用操作系统实现JSF时,我们需要考虑的是JSF基于的底层框架复杂性。

原文链接: zeroturnaround 翻译: ImportNew.com - 苏曦汀
译文链接: http://www.importnew.com/8024.html
[ 转载请保留原文出处、译者和译文链接。]



相关文章

发表评论

Comment form

(*) 表示必填项

3 条评论

  1. 徐云钊 说道:

    很不错的系列。
    不过读了两遍似乎还没读懂这章讲的是什么意思?
    首先份数越高证明这个框架越轻量吗?似乎Play框架很复杂,但是不是据说使用起来很简单吗?这个复杂性是说框架本身吗?但是既然是用框架而不是重新构架一个框架这个框架本身设计复杂与否应该没关系吧,应该是考虑是否容易扩展吧?

    Thumb up 1 Thumb down 0

  2. 李强 说道:

    框架其实是对底层地封装的东西,它可以直接用底层实现,但是本身方便易用,实际上隐藏了内部复杂性,复杂性由系统承担。不过因为封装性,所以内部无法改变,所以具备局限性,在实际中涉及到项目开发过程需求这样经常遇到的情况会非常体现它的巨大价值.

    Thumb up 0 Thumb down 0

  3. liu 说道:

    没有adf?

    Thumb up 0 Thumb down 0

跳到底部
返回顶部