世界顶尖运动队教练的成功秘诀
本文列出了来自于顶级教练Marc Lammers的9条原则，他是在打造世界最佳曲棍球队的过程中发现这些原则的，文章把这些原则映射到了软件开发实践之中。
新闻
Web框架满天飞，我们还需要构建自己的吗？
作者 Alexander Olaru译者 张龙 发布于 2008年1月23日 下午8时21分
在No Fluff, Just Stuff会上经常发言的Neal Ford最近写了一些关于Craptaculous Web框架 的文章，这些文章使用了Jay在会议上发布的关于开发者目前都在使用何种web框架的投票所收集的一些结果。
一般来说， Struts的使用数量依然占统治地位（但是最近他一直在调查在一个新的项目上有多少人会选择Struts，而结果 却是数量大幅下降）。他又悉数论述了web框架（毕竟在Java世界中web框架太多了）。在我所在的分会场，我问有多少人在使用他们自己的，土生土长的 “Craptaculous”框架。非常有趣，有很多人举手。这个土生土长的Craptaculous框架打败了一些知名对手，像JSF（谢天谢地）和 Tapestry（不好意思）。
Neal认为这个现象表明了Java界对于web框架认识上的混乱。他说如果人们只有3个选择的话，他们就可以直接比较它们了；然而当人们面对10 个或者20个选择时，麻烦就来了，他们会选择Struts收场或者干脆创建一个他们自己的框架。他将这种情况类比于果酱店这个经典实例（Paradox of Choice: Why More Is Less 一书描述了果酱店实例）：
一个小商店开始派送果酱来吸引顾客。当他们提供3种不同口味的果酱时， 顾客会品尝他们，果酱卖的也非常好。更多一定会更好，难道不是吗？于是他们提供了10种不同的口味，但是销量却急剧下降了。当面对太多选择时，人们的决定能力就会下降。
Neal又以Groovy为例继续论述，Grails作为主流的web框架会促使开发者采用Groovy语言。因为它运行在JVM之上，他甚至相信 Grails“会拯救Java开发者现在仍在使用的土生土长的Craptaculous框架”。博客上的其他评论者认为在这些市场上甚至还存在更多的分 支。在Python世界中，框架的数量从20个减少到4个，存活下来的这些框架都彼此相当，谁都无法独领风骚；然而在.NET中，与大家期望的 ASP.NET MVC（InfoQ.com的Jonathan Allen报道过）相比，其他的框架就不值一提了。
正如Charlie Collins说到：即使选择很多，人们有时还是倾向于构建他们自己的解决方案，其他语言中web框架的繁荣证明或许有选择也是好的。
买果酱时，我只想做一个5秒钟的选择并且不期望有“太多的选择”。 但当选择配偶，买房子或者作出任何长期或者代价高昂的决策时，比如选择一个我将长期使用的框架，我期望选择会尽可能地多，而不是少。
Charlie解释了为什么他坚信会有很多的Java web框架：
Java的核心问题就是过多的web框架。但那是人们以不同方式来解决复杂问题的一种表现方式（很多问题并不是他们的错，而是HTTP协议的工作方 式造成的）。如果你想选择一个框架来帮助你，不要仅仅是随便看看，请你多花些时间，以此来了解你的需求是什么，同时深入的研究框架的细节来做出决定：到底 哪种框架才能真正满足你的要求。
聪明人以新的方式来看待问题，以不同的方式来解决问题，所以我认为Java是非常开放，非常健康的，而不是向相反。
你有什么想法呢？这么多的Java web框架是好还是不好呢？
查看英文原文：In a World of Web Framework Choices, Some Developers Still Build Their Own
译者简介：张龙，同济大学软件工程硕士，现就职于理光软件研究所。主要从事文档工作流和办公自动化解决方案的研发工作。热衷于Java轻量级框架的研究，对敏捷方法很感兴趣。曾有若干年的J2EE培训讲师经历。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。
相关厂商内容
也许框架的核心和扩展分离.会更好一点.最好让他们之间耦合性更小.
发表人
xf w
发表于
2008年1月23日 下午8时51分
Re: 也许框架的核心和扩展分离.会更好一点.最好让他们之间耦合性更小.
发表人
凉粉 小刀
发表于
2008年1月23日 下午11时33分
Re: 也许框架的核心和扩展分离.会更好一点.最好让他们之间耦合性更小.
发表人
键 仝
发表于
2008年1月25日 上午3时36分
果酱？
发表人
fan fan
发表于
2008年1月29日 上午7时24分
Re: 果酱？
发表人
志浩 张
发表于
2008年3月2日 上午7时45分
-
JAVA下的WEB框架很多显得臃肿.也许只使用一些小功能,却要承受那么多而杂的模块相互耦合.也许框架的核心和扩展分离.会更好一点.最好让他们之间耦合性更小.用户来选取自己需要的东西.而不需要做一个很小的项目,却要加载 几十M 的jar.
-
一个小商店开始派送果酱来吸引顾客。当他们提供3种不同口味的果酱时， 顾客会品尝他们，果酱卖的也非常好。更多一定会更好，难道不是吗？于是他们提供了10种不同的口味，但是销量却急剧下降了。当面对太多选择时，人们的决定能力就会下降。
这个例子太贴切了。 -
选择太多是挺恶心的，尤其现在的框架都想包干。我现在倾向于Servlet，咔咔。把更多的逻辑扔给前台。
-
但是对于一个专业人士，比如调料大师，高级大厨，他们都是懂果酱的内行，显然，他们更希望有更多的果酱来选择，来满足自己的不同的需要
-
真有意思，什么时候都别忘了发明计算机的初衷！
5 条回复
回复