表现层框架Struts/Tapestry/JSF架构比较

05-09-15 banq
表现层框架Struts/Tapestry/JSF架构比较
  表现层技术门派众多,陷阱多多,如何在他们之间根据自己应用做一个合适选择?。

http://www.jdon.com/artichect/sjt.htm

hgwnet
2005-09-17 08:18
框架框架,框框太多,甚至厌恶这些框架发起人作为程序员的呆板。
性能优异要是就算了,但在追求大而全的情况下看不出哪个所谓主流框架非常满足作为web所需的敏捷。看看所谓的组件框架struts,webwork,一大堆的所谓i18n、组件简直就是画蛇添足。看看某国外最新的论坛系统,由于采用了webwork,系统简直就是慢如蜗牛。
再说tapestry,组件化思想贯穿整个系统设计,无疑走在潮流的前端,同时众多组件也基本可满足日常开发,更可贵的是,它的性能比webwork还好,更不用说JSF了。但它的缺点也很明显,框框太多。也不知道那个大胡子是怎么想的,为了追求框框的完美,本身可3.0可简单获取HttpServletRequest控制权的,4.0非要你手动注入request服务,这简直就是在颠覆框架易用性的本质!当然了,若你要走组件化开发道路,还是得用tapestry,否则JSF,Tubine,webwork之流总有一天会把你搞垮。
与其被框死,还不如自己搞个自己的框架。我现在就用自己的纯jsp框架,什么Form validator、i18n、actions样样都有,开发起来敏捷不说,而且性能跟单纯的jsp无异,爽。

banq
2005-09-17 09:22
hgwnet 是经验之谈,Java世界这个“百花齐放”现象不但表现在表现层框架技术:

在组件级别也是,例如EJB2.x EJB3 Spring等等,都是各说各有理,但是我都觉得他们各有缺点,性能都不好,我所以搞了Jdon Framework。

在我的框架中,不但集成组件层,也通过实践,选择最方便快速开发的表现层框架或持久层技术整合进入,现在犹豫不定是选择JSF还是Tapestry。所以我写了这篇文章帮助自己理清思路。

持久层技术也一直在打口水仗,从hibernate诞生就开始这种争执,所幸Java persistence标准要出来,希望结束这种小孩式的互相指责。





hgwnet
2005-09-18 08:00
很快我也将推出我自己用的纯jsp框架,该框架目标很简单,就是充分引入form validator,action,i18n等内容,充分焕发jsp简单易用、开发灵活、高性能的生命力。框架设计基本完成,近期将对外免费发放所有源代码。

alfra
2005-09-19 21:52
期待中,什么时候能出来啊?

banq
2005-09-20 08:35
这里也有一个国人的Web框架,链接:

http://www.jdon.com/jive/thread.jsp?forum=91&thread=22490

zhaoping_yu
2005-09-20 10:15
我对hgwnet老兄的观点颇有同感。我们公司接触使用Struts可以说是比较早了(大概是从Struts刚推出不久就开始了)。当时Struts也比较轻型,其对MVC的实现确实给我们WEB项目的开发带来很大的方便。但Struts后继版本的发展,我们对其的使用反而越来越不方便了、代价越来越高。首先是Struts本身越来越庞大,原因是它想包含的功能越来越全(如果只是扩展表现层必须的功能也就罢了,可它为什么把数据库等有关的功能也考虑进去啊(我当时用的版本是这样的,其最新的版本是不是还考虑,我没有考察)),导致我们的WEB应用越来越慢,员工的学习曲线越来越陡。它提供了那么多TAG,我们大部分用不到,而且我们需要的它又没提供(或至少不是太对口)。于是我们公司就根据Struts实现MVC的原理实现了自己的MVC框架,它只考虑实现了MVC最基本的东西,相关的代码才十几K,用它替换原先的Struts后,经过相关测试,给我的感觉就象一个人脱掉笨重的外套一样。后来我们公司就一直用这个框架,也没发现对其还有太多的扩展需求。由于这个框架对我们公司来说已经够用了,在Struts后面出现的其他MVC模式框架,我们公司也没有对它们进行跟踪使用。
我写这个并不是排斥使用各种编程框架,相反,如果有好的框架当然要拿过来使用;如果当前的框架对公司目前的项目够用就行了,也没必要去盲目地追求新的框架;使用框架还要考虑学习成本。我们对框架实现者的要求是,开发框架时一定要考虑框架的功能定位,不要去追求大而全的东西。我们需要的是定位准确、容易学习和使用、轻量级的框架。

banq
2005-09-20 15:33
zhaoping_yu非常有道理,这也是所谓行业框架的诞生原因,也许我这个行业的表单界面都不复杂,那么我就不可能用到Struts那么全面的功能,相反,自己做这样一个轻量框架反而适合自己,和穿鞋的道理一样的。

我认为这也是Java世界与.NET的最大区别,我这里不想引起两者讨论,我看到很多比较文章,它们都是从技术上进行一对一比较,其实这没意思,缘木求鱼,Java提供给我们不只是用工具,还有自己编写自行解决工具的能力,这方面能力要比.NET世界以M$为主的软件要强多。我这里只是提一下,不想引起比较讨论。

zhaoping_yu
2005-09-21 08:48
容我再补充两句吧。
再次郑重声明,我们并不排除使用现有的各种框架,更不主张自己非要重新开发“适合自己”的框架,相反如果有好的框架我们会很乐意使用的(我们更乐于把自己的主要精力放在自己业务的开发上,我们公司用过的框架:webmacro、village、ecp等想必大家有的都没听说过吧?我们对Struts还是非常赞赏和喜爱的),我想表达的观点是:
1、如果要适合自己的框架,一定要毫不犹豫地拿过来用,而且一定要踏踏实实地把它用精、用熟。
2、不要盲目追求技术潮流,只要是当前的框架够用了,就不要再去追求“更好”的。要知道,作为一个公司,如果重新换另一个框架,就要对整个技术团队进行重新培训、学习、重构和维护等等,成本太大了。
3、如果当前的框架实在满足不了项目的需要,可以考虑对当前的框架进行“重构”(我想这也是开源项目的优点吧),前提是你必须对这个框架首先要用精用熟。
所以我们对框架的要求是:框架只做它应该做的事(并做好),但要允许我们应用开发者根据需要对其做适当的适配和扩展,而不要做一个大而全的东西,用来满足我们各种各样的需求。
4、框架应该象模式一样,从实践中来到实践中去,只有从实践中提取出来并放到实践中去检验它,适合自己项目的框架就是好框架。不要泛泛地光从“技术”层面去讨论它们的好坏,要知道一个框架被提出来肯定有它的存在的基础和道理的。
5、当然,如果刚开始选用一个框架时,确实需要在目前现有的同类框架中进行对比比较,从中选一个最好的。但是在选择时不要只考虑技术因素还要考虑其他因素,比如:我们公司是否有这样的人员、技术储备?这个技术是不是对我们这样的小项目来说大材小用了?其维护性如何?等等。
(不知我的意见是不是符合我们讨论的主题,请大家和斑竹见谅)

banq
2005-09-22 08:43
zhaoping_yu 的意思是,框架架构等选择不但在技术上要进行比较,例如本文是从技术角度对这个三个表现层框架进行比较,而且要从项目管理和人员角度也进行考虑,全面权衡考虑。

那么这么多因素,哪个因素是主要的呢?我个人认为技术架构还是主要的,好的技术架构与良好的项目管理往往是一致的,那么人员素质怎么办?外请专业人员来培训和咨询。

不好意思,好像在做广告,我觉得这些话题还是应该对大家有益的。

banq
2005-09-22 09:06
这里还有一个需要不需要发明轮子的问题讨论,也就是是否轻易就动手自己写框架呢?

TSS有这个讨论可以供借鉴:

Richard Bair explains why "Not Invented Here" isn't bad

zhaoping_yu
2005-09-22 10:10
我自己从事这么多项目的体会是:除非万不得已,不要轻易自己动手写框架,那是一件极痛苦且出力不讨好的事情。现在,在开展一个项目的过程中,每当有人提出要针对本项目做一个框架或类似通用的东西时,我都极其害怕并竭力阻止,结果,大家讨论来讨论去,最后总能从现成的东西中找到比较合适的。
现在我常挂在嘴边的一句话是:最好是好的敌人!


> 这里还有一个需要不需要发明轮子的问题讨论,也就是是否轻
> 拙投肿约盒纯蚣苣兀?>
> TSS有这个讨论可以供借鉴:
> Richard Bair explains why "Not Invented
> Here" isn't bad


mythmoon
2005-09-30 12:20



-->最好是好的敌人!
回去思考!

blueoxygen
2005-10-06 15:45
当你们公司内部框架作为产品推出,一定不会满足我的他的大家的所有要求,于是,你的框架也会越来越大的。公司内部用的东西,完完全全符合自己的项目实际,除非你们公司大到几年小到1 2个月的项目此框架无需tailor通吃,那可以弄出来了。
我的意思就是,struts越来包含的东西越多,各种人用了有各种不方便原因是他是通用框架,而且是表现层的(客户会提出各种UI上的难题,而struts凡事请求action这点太不灵活了,那时我无数次想到ajax)

过眼烟云
2005-10-10 01:22
looking ahead,

struts is dying(sometimes one wonders cobol still exists).
Tapestry will struggle.
jsf is not mature but promising.

2Go 1 2 下一页