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

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
期待中，什么时候能出来啊？
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 的意思是，框架架构等选择不但在技术上要进行比较，例如本文是从技术角度对这个三个表现层框架进行比较，而且要从项目管理和人员角度也进行考虑，全面权衡考虑。

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

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

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.