框架之争——JAVA给我们带来什么

J道 hgwnet：

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

 

zhaoping_yu:

      我对hgwnet老兄的观点颇有同感。我们公司接触使用Struts可以说是比较早了（大概是从Struts刚推出不久就开始了）。当时Struts也比较轻型，其对MVC的实现确实给我们WEB项目的开发带来很大的方便。但Struts后继版本的发展，我们对其的使用反而越来越不方便了、代价越来越高。

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

 

banq:

      zhaoping_yu非常有道理，这也是所谓行业框架的诞生原因，也许我这个行业的表单界面都不复杂，那么我就不可能用到Struts那么全面的功能，相反，自己做这样一个轻量框架反而适合自己，和穿鞋的道理一样的。
      我认为这也是Java世界与.NET的最大区别，我这里不想引起两者讨论，我看到很多比较文章，它们都是从技术上进行一对一比较，其实这没意思，缘木求鱼，Java提供给我们不只是用工具，还有自己编写自行解决工具的能力，这方面能力要比.NET世界以M$为主的软件要强多。我这里只是提一下，不想引起比较讨论。

 

zhaoping_yu：

      容我再补充两句吧。
      再次郑重声明，我们并不排除使用现有的各种框架，更不主张自己非要重新开发“适合自己”的框架，相反如果有好的框架我们会很乐意使用的（我们更乐于把自己的主要精力放在自己业务的开发上，我们公司用过的框架：webmacro、village、ecp等想必大家有的都没听说过吧？我们对Struts还是非常赞赏和喜爱的），我想表达的观点是：
①、如果要适合自己的框架，一定要毫不犹豫地拿过来用，而且一定要踏踏实实地把它用精、用熟。
②、不要盲目追求技术潮流，只要是当前的框架够用了，就不要再去追求“更好”的。要知道，作为一个公司，如果重新换另一个框架，就要对整个技术团队进行重新培训、学习、重构和维护等等，成本太大了。
③、如果当前的框架实在满足不了项目的需要，可以考虑对当前的框架进行“重构”（我想这也是开源项目的优点吧），前提是你必须对这个框架首先要用精用熟。
所以我们对框架的要求是：框架只做它应该做的事（并做好），但要允许我们应用开发者根据需要对其做适当的适配和扩展，而不要做一个大而全的东西，用来满足我们各种各样的需求。

④、框架应该象模式一样，从实践中来到实践中去，只有从实践中提取出来并放到实践中去检验它，适合自己项目的框架就是好框架。不要泛泛地光从“技术”层面去讨论它们的好坏，要知道一个框架被提出来肯定有它的存在的基础和道理的。
⑤、当然，如果刚开始选用一个框架时，确实需要在目前现有的同类框架中进行对比比较，从中选一个最好的。但是在选择时不要只考虑技术因素还要考虑其他因素，比如：我们公司是否有这样的人员、技术储备？这个技术是不是对我们这样的小项目来说大材小用了？其维护性如何？等等。

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