论坛首页 Java企业应用论坛

Java Web框架前景浅析

浏览 23385 次
精华帖 (0) :: 良好帖 (12) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2013-06-30  

 

基于三(多)层架构模式,典型WEB系统的总体架构如下图所示:

在上述分层架构中,整个应用被划分为两大部分:

  • 客户端:基于浏览器提供信息展现、用户交互等功能。所采用的技术主要有:HTML/HTML5、Javascript、CSS。另外,Flush由于其广泛的浏览器集成度,通常也可归纳为一种WEB技术,但Flush不在本文讨论范围。
  • 服务端:实现业务逻辑处理。通常按三层架构模式划分为展现层、业务逻辑层和数据集成层。服务端的平台选择相比客户端来讲更加广泛,有PHP、Java、.Net、Ruby、Python等。每种平台下都有非常优秀的WEB框架可供选择。

尽管客户端的WEB技术平台主要还是基于HTML+Javascript+CSS,但是基于其上的类库、框架、开发模式、衍生技术等非常繁杂且变化多端,要在实际项目中做出最好的选择绝非易事。有鉴于此,本文不打算深入讨论客户端WEB技术。

服务端虽然平台选择非常多样化,但总体架构基本一致。本文主要讨论Java平台。在所有平台中,Java平台下的WEB框架是最多的,其它语言平台下新的框架总能在Java中找到对应的实现。这也是Java平台生命力强大的体现之一。下图列出了Java平台下的部分Web框架:

上图共列出了62个Java Web框架!一定还有很多Java Web框架没有收录其中。

不过不要担心,在Java世界,流行的或说主流的Web框架并不多,如:Struts、Spring MVC、Play! Framework、GWT、Apache Wicket、JSF等,国产的Java Web框架有EOS、Nuts等在一定范围使用也比较广泛。

  • Struts:这是Java社区最老牌、知名度最高、使用也最广泛的WEB框架。Struts的特点是简单易用、文档丰富,通常与spring-hibernate/ibatis组合使用(SSH/SSI);
  • Spring MVC:Spring当年凭借一句"J2EE Withou EJB"的怒吼拉开了开源社区全面对抗学院派(JCP)的序幕,这一战让Spring一举成名。凭借Spring的东风,其mvc框架也得到社区广泛关注。基于Spring的IOC、AOP等技术,其框架设计简洁优雅、扩展性非常强;
  • Play! Framework:这是Ruby社区非常火爆的Ruby On Rails框架在Java平台的翻版。当年Ruby On Rails的约定优于继承、极简的ORM框架所带来的快速开发能力与当时Java社区经典的SSH中繁杂的XML配置、越来越臃肿复杂的ORM所导致的开发效率的低下形成了鲜明对比。Play!就是这种理念PK下的产物;
  • EOS:国产的基于构件理念的Java开发平台,其图形化的业务逻辑编排能力让许多人眼前一亮,对SOA不遗余力的支持也体现了厂商的态度。EOS的页面流概念应该算是WEB框架领域的一个创举,此前或此后还没有哪个WEB框架考虑过多个请求之间的关联性问题。除此之外,EOS的WEB框架也算中规中距;
  • JSF:2001学院派发起JSR,至2004年推出规范1.0、2006年推出1.2版参考实现、2009年发布2.0规范、2010以后JSF2得到了以JBoss为首的广泛支持。然而时至今日,JSF仍然不温不火,其成就远没有Struts或Spring MVC来得高。不过个人认为,相比前面所说的所有框架来讲,JSF的设计理念是非常先进的。JSF是Java世界中非常少见的以组件为中心的WEB框架!补充一点,金蝶2007年推出的OperaMasks当年高调宣称其基于JSF的框架是世界一流的,但时至今日其官方网站几乎停止更新,着实让人不甚唏嘘;
  • GWT:Google出品的Java WEB框架,倡导使用传统桌面应用开发方式来开发WEB。开发人员不需要懂WEB技术,只需要熟悉Java和面向对象理论,就可以使用类似Swing或RCP的方式开发WEB应用。这一点与eclipse的RAP非常相似。GWT适用于从传统桌面开发转向WEB开发的人群,对于真正了解WEB技术的开发人员来讲,其开发模式很难让人接受;类似这样的框架还有apache wicket等;

每个框架都有各自的特点和使用人群,很难一概而论说哪个好哪个不好。不过从下图中我们可以大致了解开发人员的选择:

 

尽管Java Web框架各类繁多,不同的框架有不同的特点,但不同的框架之间还是有许多共性的。例如,按照页面和处理逻辑的关系我们可以将Java WEB框架划分为:

  • 传统MVC模式的WEB框架:如Struts、Spring、Play!等。这一类框架的特点是页面和处理逻辑按照传统MVC模式进行组织,页面通常使用JSP或某种模板语言(如Freemarker、Velocity等)来实现,服务端处理逻辑通常采用Action或Command模式;
  • 以组件为中心的WEB框架:如JSF。传统MVC框架的请求处理流程通常是“请求-处理-页面”的循环,而在JSF中请求的处理是基于事件的,这种开发模式类似于桌面程序的开发模式,只是页面还是使用JSP加JSF标签组件而已;
  • 模拟桌面开发方式的WEB框架:如GWT、Wicket等。这类框架纯粹使用桌面方式进行WEB开发,开发人员基本不需要知道HTTP及HTML/JS/CSS等知识。这类框架相比JSF更加激进,不仅请求处理模式基于事件,连页面展现也是按照传统桌面方式去开发;

上述三类框架中,第一类是最靠近WEB的开发方式,第三类是最靠近桌面的开发方式,第二类界于两者之间。桌面开发方式的好处是组件化能力非常强,借助发展多年的桌面控件设计经验,可以很容易地设计出复用度非常高的组件。相对的,第一类开发模式下由于界面变化非常大,在展现层就很难做出组件化的设计(这其实也体现了WEB应用展现及交互方式变化多端的内在本质)。

另一方面,第一类框架非常强调客户端与服务端的分离,而第三类框架则试图弱化客户端与服务端的界限,其理想模式是客户端事件直接传递到服务端,中间没有任何转换(这就是桌面程序的模式了)。

考虑现实世界的复杂性以及WEB千变万化的特点,第一类框架只是做好自己的份内事,将客户端的处理交由专门的客户端框架去实现(这样才能充分利用当前欣欣向荣的客户端WEB技术);而第三类框架则试图通吃客户端与服务端,完全无视客户端的特点,这将导致第三类框架只能局限于某些特定领域的应用范围之内,而且随着客户端WEB技术的发展,其应用范围必定越来越狭窄。至于第二类框架,界于前两类框架之间,地位非常尴尬,尽管其有官方正统的血统背景,但其违背WEB大的发展趋势,其前景不被看好。

   发表时间:2013-06-30  
多年来使用的WEB框架主要是Struts,对Spring MVC及Play有所了解,对JSF及GWT则知之不多,若有理解不对的地方,欢迎拍砖。
0 请登录后投票
   发表时间:2013-07-01  
未来的方向也许不是任何楼主列出的东西。前端应该是js写出的客户端,而服务器端提供数据。类似传统的cs模型,只不过client从安装的软件变成了运行在浏览器中的js。目前的SPA,但页面应用就是这个潮流。GWT的结果与之类似。
0 请登录后投票
   发表时间:2013-07-01  
wumingshi 写道
未来的方向也许不是任何楼主列出的东西。前端应该是js写出的客户端,而服务器端提供数据。类似传统的cs模型,只不过client从安装的软件变成了运行在浏览器中的js。目前的SPA,但页面应用就是这个潮流。GWT的结果与之类似。


非常同意,从一个专业的流程上来看,java应该只存在于服务器端,至于接收的是http还是其他的tcp是另说,前端应该由更加轻量级更加灵活的语言来搞定
0 请登录后投票
   发表时间:2013-07-01  
须等待 写道
wumingshi 写道
未来的方向也许不是任何楼主列出的东西。前端应该是js写出的客户端,而服务器端提供数据。类似传统的cs模型,只不过client从安装的软件变成了运行在浏览器中的js。目前的SPA,但页面应用就是这个潮流。GWT的结果与之类似。


非常同意,从一个专业的流程上来看,java应该只存在于服务器端,至于接收的是http还是其他的tcp是另说,前端应该由更加轻量级更加灵活的语言来搞定


同意两位的观点。

我认为给客户端与服务端划分明确界限是末来WEB的方向。基于此,任何试图模糊两者界限的框架都是吃力不讨好的做法,比如GWT。而JSF之流本质上也是希望开发人员不必关心客户端与服务端的区别,因此JSF也不是末来的方向。

而类似struts/spring mvc/play等框架,由于它们明确区分了客户端页面和服务端逻辑,末来不论客户端WEB的开发方式是采用jquery/easyui,或是采用extjs,或者是backbone,服务端的逻辑总是少不了的,因此这样的框架还是有用武之地的。差别只是服务端的代码组织方式不同,或者对服务端的要求不同(比如以前struts需要用jsp生成html页面,以后可能更多的是生成json数据)。

至于末来客户端WEB的开发方式是怎样的,个人认为现在还不能一概而论,这一点我准备另写一贴与大家讨论。
0 请登录后投票
   发表时间:2013-07-01  
jxb890113 写道
须等待 写道
wumingshi 写道
未来的方向也许不是任何楼主列出的东西。前端应该是js写出的客户端,而服务器端提供数据。类似传统的cs模型,只不过client从安装的软件变成了运行在浏览器中的js。目前的SPA,但页面应用就是这个潮流。GWT的结果与之类似。


非常同意,从一个专业的流程上来看,java应该只存在于服务器端,至于接收的是http还是其他的tcp是另说,前端应该由更加轻量级更加灵活的语言来搞定


同意两位的观点。

我认为给客户端与服务端划分明确界限是末来WEB的方向。基于此,任何试图模糊两者界限的框架都是吃力不讨好的做法,比如GWT。而JSF之流本质上也是希望开发人员不必关心客户端与服务端的区别,因此JSF也不是末来的方向。

而类似struts/spring mvc/play等框架,由于它们明确区分了客户端页面和服务端逻辑,末来不论客户端WEB的开发方式是采用jquery/easyui,或是采用extjs,或者是backbone,服务端的逻辑总是少不了的,因此这样的框架还是有用武之地的。差别只是服务端的代码组织方式不同,或者对服务端的要求不同(比如以前struts需要用jsp生成html页面,以后可能更多的是生成json数据)。

至于末来客户端WEB的开发方式是怎样的,个人认为现在还不能一概而论,这一点我准备另写一贴与大家讨论。


怎么说呢,jsf也好,struts也好都有存在的价值,就是他们适用于开发那种需要快速搭建而且对UI没有特别要求的后台页面,优势很明显:搭建迅速,一个人搞定从后端到前端,所以大部分企业级应用的web都是jsp,当面对对UI有复杂要求的时候用jsp就很吃力,因为java工程师要去负责js、css,这个很痛苦,所以在稍微大型且正式的项目里,都不会在前端使用jsp这种东西
0 请登录后投票
   发表时间:2013-07-02   最后修改:2013-07-02
确实,现在服务端的WEB框架基本也就那样了,看不出末来会有什么大的变化。相反现在WEB前端的开发模式、开发框架还远末定形。关于前端的开发框架及开发模式,个人也写了一篇帖子做了简单总结:WEB开发模式浅析
0 请登录后投票
   发表时间:2013-07-03  
jxb890113 写道
确实,现在服务端的WEB框架基本也就那样了,看不出末来会有什么大的变化。相反现在WEB前端的开发模式、开发框架还远末定形。关于前端的开发框架及开发模式,个人也写了一篇帖子做了简单总结:WEB开发模式浅析

看来大家的观点基本都一致,服务器端和客户端分工越来越明确,他们的界限越来越分明。

结合移动互联网,服务器端API化是趋势。
0 请登录后投票
   发表时间:2013-07-03   最后修改:2013-07-03
楼主这两篇文章很有水准。

对于第三类web框架(类桌面应用、组件模型、基于事件),我觉得在企业应用领域有很大优势,
采用第一类web框架至少需要掌握Java、html、js、css,而第三类web框架只需要Java;
需要的技能多且杂,会导致团队内出现前后台分工,而分工又带来沟通成本、集成成本以及生产不均衡。
另外js相对于java语言随意性大、调试困难、单元测试困难,不利于大规模团队开发。

另外,html、css、js还有挥之不去的浏览器兼容问题。

GWT之类的第三类框架把html和js看作是web领域的汇编语言,将开发人员从web底层技术细节中解放出来,提高了生产力。
当然代价就是对最终页面效果的控制不够直接,效果不够绚,做出来的界面千篇一律。

这个领域,除了GWT以外,推荐大家看一下zk和vaadin这两个框架。
0 请登录后投票
   发表时间:2013-07-03   最后修改:2013-07-03
其实所谓的“B端/S端明确分离”就是当年一帮搞js的家伙看到服务器端胆敢跟前端抢饭碗搞出来的概念,楼主不要太当真了。当年叫嚷“B端S端分离”的javascript牛人们现在都去玩node.js了,再也不提什么“前后端界限要清晰”了, 恨不得浏览器加node.js加MangoDB一杆到底。说白了,其实谁都想用最小的学习成本多揽点活。

从现实角度来看,追求快速反应的互联网应用完全可以选择RoR,PHP之类的动态语言框架。稳打稳扎走java路线的多是企业应用,这种公司拚的是渠道和行业积累。软件层面做到中规中矩,能准确实现业务需求就差不多了。最重要的是能跨时间,跨团队维护(原始开发者离开后能快速接手维护,有比较紧的项目可以临时调集人手冲)。这种前提下,如果选的框架刚好封装了一些前端特性,可以提高一下用户体验,何乐而不为。至于专门组一个前端团队,又未必有这个必要(能养得起那自然是好)。

简而言之,如果我的项目里有大半工作量都在前端,我在后端就根本不需要用java,有很多更好的选择。这时楼主列的第一类框架地位就很尴尬了……从楼主给的图就可以看出,struts的份额在缩小,其他主要框架的份额大致不变。流失的部分去哪了?显然被其他非java框架(play! framework的scala版也算喔)挖走了。那么从java web框架本身的角度来考虑,至少到目前为止走整合前端路线才是正路。
11 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics