转自IT168 觉得对框架的认识和定位很有帮助，虽然讲的不是php，但是思想是一致的。
1 空前繁荣的开源世界
大致2000年以前，Java世界还是Sun一言九鼎，唯我独尊的时代。Sun发布的任何规范和标准都无一例外地被Java社区有意无意的追捧着，Java世界沉浸在一片歌功颂德，前拥后簇的氛围里。IBM，Bea，Oracle这些Java阵营的代表者也都为能最先最快实现Sun的各种规范而弹冠相庆。
但这三四年来，Java的列车驶进了春秋战国百家争鸣，百花齐放的时代， Apache，JBoss，opensymphony，Eclipse，Codehaus等开源组织个个门庭若市，车水马龙。Java世界似乎天天在过年——张灯结彩，新桃换旧符。打开theserverside.com网站，每天映入眼帘是一条条各种开源项目发布、升级的新闻。虽然嘈杂了些，但却异彩纷呈，惊艳四座。在Java世界里，十室之内必有隐士，十步之内必有芳草，有才华的程序员太多了，抑或怀才的程序员被独裁式的统治压抑太久了，一旦找到了海德公园，庞涓、孙膑、苏秦、张仪式的高手纷纷走出隐居的鬼谷，在开源舞台上劲舞一支，高歌一曲，用一个个开源项目彰显着自己独特的魅力。
从客户端到数据库，从页面流程控制到业务流程控制，从全文搜索到地图搜索，从论坛到博客，在各种应用领域你都可以方便地找到多个相似的Java开源框架。开源框架的空前繁荣有力的促进了Java技术的交流和分享。一些面向开源的社区，论坛纷纷建立，国内比较著名的就有满江红开源论坛、中文Spring论坛、JavaScud开源平台、JavaEye社区等，宣讲、争论、协作、互动，无数激情和智慧碰撞出耀眼的火花。
随着开源项目的日益增多，国内甚至出现了象open-open.com Java开源大全的汇总整理网站，它如一个开源项目的大集市，将开源项目分类整理，提供简要的描述说明信息，方便使用者了解、查询和比较。
开源项目的繁荣还为技术图书业创造了机会，不管是国外的Amazon，还是china-pub或dearbook，开源框架或产品的技术图书，如Spring，Hibernate，Struts，Eclipse等等都成为荣登榜首的畅销先锋。
这场几乎来源于民间的开源飓风给开发者和CTO们的思路和决策带来了巨大的影响，据Bea的调查，全球排名前2000家软件开发公司中有70%以上在使用一种或多种开源框架——多达28%的公司在开发环境中使用了一种以上的应用服务器。
同时开源也给走传统路线的Java巨头们带来战略性的影响：Sun去年宣布将其旗舰产品——Solaris开源；去年IBM向第三方厂商开放了其高性能通用并行文件系统（GPFS）的源代码；Unisys也改变企业战略定位投入开源怀抱等等不胜枚举，它们纷纷将营利模式从原来的产品销售调整为支持与服务。
2 开源框架带来的烦恼
虽然开源的框架、类库越来越丰富，可供选择的替代者越来越多，但Java程序员却感觉自己慢慢陷入到了技术的漩涡之中：因为他们发现只要一段时间不关注开源社区，就有潮水般陌生的技术框架、专业术语、英文缩略词挟裹着一团团亢奋的热浪将自己淹没，让他们觉得随时都有被Java世界抛弃的危险。许多年纪稍大的程序员甚至觉得职位转换，甩掉技术干管理已经时不我待。
选择的困惑
雨后春笋般涌现的开源框架都声称自己是最好的，有过多次因盲从于技术鼓吹而失望伤心的经历后，现在的开发者都变得成熟理智了，他们不会轻易相信某个框架自身的承诺，不会轻易附和他人的宣传，这确实是件好事。为了作出理智的选择，他们往往要自己亲自摸索以做出评判。
有时，我们会发现向上司推荐一个框架已经变成一件困难的事情，因为上司会冒出各种各样的问题：如Webwork比Struts好在哪里？Hibernate和iBatis有什么区别？OpenWFE比之jBpm有什么优势等等。所以要确定一个框架时，往往需要将相似的框架都研究一遍，以便有充足的理由让上司相信我们的选择是最优的。
但是，要将同类的框架都做一次研究并比较优劣并非易事，如开源工作流引擎就有Willow，OpenWFE，jBpm，Werkflow，OSWorkflow等不下30余种的框架，炫耀的声音一个比一个响亮。每种框架都有自己的设计思路和实现方案，况且这种技术预研性的工作，又不可能在项目周期内占用太多的时间，而不深入预研又不可能客观地作出评判，所以往往是熬红的双眼依然带着迷茫的目光。
此外，用人单位为了减少新员工的培训时间，对求职者往往有明确的框架使用技能和经验的要求。求职者为了能找到一个好工作，不得不逼迫自己学习更多的框架，以便让自己拥有更多的求职机会。
搭配的困难
开源的繁荣虽然给各个领域都造就了许多优秀的框架，如Spring，Struts，Hibernate，Lucene、OSCache等等，但却没有出现一个一站式，统管全局的整合开发框架。开发者在享用大餐之前，事先得充当大橱的角色，将这些盐，油、酱、菜按合理的方式调配好。
虽然，我们一直强调整体大于单个的总和，但是如何将单个“个体”正确的组合成发挥更大效应的“整体”却并非易事。因为这些单独的框架都由不同的团队开发，框架与框架之间存在天然的阻抗，这种框架和框架之间的“代沟”需要额外配置和编码才能弥合。
每个框架都拥有自己的配置文件，框架的整合经常带来配置的灾难，如将Spring和Struts整合时，不仅Struts本身的配置文件一个不能少，在Spring中还需要每个Action提供配置信息，而且两者需要遵守一定的契约。
相互搭配的框架和框架之间经常会出现相似的或重复的功能，如何取舍，如何使用往往让开发者们为难。如Spring本身提供了AOP方法返回结果的缓存功能，而Hibernate本身也提供二级缓存，究竟两者都使用呢，还是择一而从？往往中间又会引出很多争论。
框架整合的问题已经日益突出，我们可以在各开源论坛或社区发现大量有关讨论的主题。目前也出现了一些试图解决的框架整合问题的开源项目，如国外的AppFuse，国内的SpringSide，为框架的整合提供了专业的指导。但是并没有很好的解决现实开发中的实际需要。这些整合框架为了增加通用性，网都撒得太大，导致整合框架本身象一个庞然大物，让人望而生畏，定制性和灵巧性上都存在不足，降低了它们的实用性，所以这些整合性的开源项目往往降格为指导性的实例。
升级的困扰
活跃的框架每天都在升级改造，丰富功能。其次由于开源框架在一定程度上存在随意性，往往导致框架在实际使用后，发现大量隐含的Bug，所以有时对某个框架的升级变得不可避免。开源框架比之Sun正规的规范有着更加灵活的升级方式，高低版本不兼容的问题已经成为司空见惯的事情。如著名的Hibernate，其3.0版本和2.0版本的包名都发生了彻底的变化，刚发布的Acegi和低版本也存在很大的差异，无法兼容。
一个整合性的框架由多个出自于不同团队的框架组成，整合框架在这些组合框架之上高位运行，底层框架的升级变化就造成了组合框架水涨船高的局面，整合框架脆弱的稳定性很容易被打破。
组合框架的升级还直接带来了开发团队学习的压力，为了熟悉框架新功能和改进，在开发工作之余，他们不得不努力压榨自己的业余时间不断地充电学习。总是某个框架新功能学习还未完成，另一个框架的新版本又在一阵欢呼声中闪亮登场，让开发人员发现自己所有的努力只是一场骑牛追马游戏。
3 开发者如何走出迷局
框架的爆炸性增长和技术更替一日千里的速度，让刚刚从传统J2EE迷局中走出来的开发者重新堕入了新的困境之中。有许多切身体验的开发者在网上大倒苦水，甚至有许多声音在呐喊，希望重新回到JSP+JavaBean＋JDBC那个纯真的年代中去。
框架的作者们本想还软件开发一个清新美满的世界，不想个体性的良性企盼变成了一种整体性的混乱纷争。在纷繁复杂的开源世界如何走出迷局和困境，把握自己技术航船的方向，是每个开发者们冥思遐想的事情。
重点学习 触类旁通
每个人的时间是有限的，对于周期紧，进度急，加班赶的开发者来说更加如此，使得开发者不可能 “识遍天下字，读尽人间书”逐个学习框架。选择好适合自己、适合项目的框架进行重点学习尤为重要。不但要掌握技术细节，更要理解框架的原理和思想，这样在接触相关框架时，我们才能触类旁通，慧眼识真。
如果你深入理解了Struts框架的MVC的原理和思想，在接触Tapestry，Spring MVC等框架时，你会发现两者只是形上的区别，而非质上的差异，即使因现实需要确实要转换框架时，也可以轻松平滑地过渡。
不求最好 但求适用
开发人员往往都是完美主义者，吹毛求疵，带着浓重的偏执狂倾向。是的，偏执狂是优秀程序员的一个特点，时下《只有偏执狂才能生存》也正在大卖热卖，Rod Johnson，Gavin King，Oberg也都是偏执狂。
但在有进度工期压力的情况下，我们不得不向实现妥协。对于公司来说，利润永远都是第一位的，不管用不用框架或用什么框架，只要能如期保质保量完成用户的所有功能需求，就是最好的项目。客户永远看不到，也不关心你使用了哪个优秀的技术和框架。
所以，在实际的开发中，也许我们常常需要委曲内心的冲动，只要目前的框架能满足需求，我们没有必须象服装界一样赶追时髦，一切不求最好，但求适用。
如果Spring Template JDBC已经很好的满足了目前的需求，就没有必要一定要上Hibernate，如果自己开发的简要列表控件效果不错，就无须转换为ExtremeTable。新框架的学习需要代价，但这种代价的价值在实际发挥功效之前是不被肯定的。况且看似不合时宜的那些简单而古老的技术也可以做出强大的系统，如世界上最大的java项目——巴西全国医疗系统，就是构建在JSP＋JavaBean＋Servlet之上。
注重积累 搭建平台
我们常常发现一些软件公司自身没有任何积累，完全寄希望于这些整合框架解决所有的问题。开源框架解决的都是某个领域的通用性问题，每个公司由于其所处行业，服务用户的不同，要求公司拥有自己的解决方案，框架的通用性和公司的个性化需求是存在矛盾的。软件公司应该加强自身的积累，在这些框架的基础上搭建好符合自身需求的快速开发平台，屏蔽掉底层框架的复杂功能和细枝末节，降低对开发人员的技能要求，以便新员工能够快速参与到项目中，而无需进行一个个开源框架的学习。
虽然这种积累和平台的建设会耗费额外的工作量，但首先它是一个循序渐进的过程，其次这种任务仅由两三个技术突出的技术人员承担，带来的好处是直接降低了其他开发人员使用难度和技术要求，在一定程序上避免了开源框架的所带来的不稳定性影响。
4 小结
开源的繁荣带来了丰富的框架，有力的推动了业界的发展，同时我们也看到，这种繁荣所带来的惊喜背后紧跟着许多困惑的眼神，迷失在繁荣的混乱之中的开发者们希望走出困惑，走出迷局。
如何在嘈杂喧闹的开源世界把握方向寻求突破，不管是对于开发者还是软件公司的决策者都值得深深的思考。
1 空前繁荣的开源世界
大致2000年以前，Java世界还是Sun一言九鼎，唯我独尊的时代。Sun发布的任何规范和标准都无一例外地被Java社区有意无意的追捧着，Java世界沉浸在一片歌功颂德，前拥后簇的氛围里。IBM，Bea，Oracle这些Java阵营的代表者也都为能最先最快实现Sun的各种规范而弹冠相庆。
但这三四年来，Java的列车驶进了春秋战国百家争鸣，百花齐放的时代， Apache，JBoss，opensymphony，Eclipse，Codehaus等开源组织个个门庭若市，车水马龙。Java世界似乎天天在过年——张灯结彩，新桃换旧符。打开theserverside.com网站，每天映入眼帘是一条条各种开源项目发布、升级的新闻。虽然嘈杂了些，但却异彩纷呈，惊艳四座。在Java世界里，十室之内必有隐士，十步之内必有芳草，有才华的程序员太多了，抑或怀才的程序员被独裁式的统治压抑太久了，一旦找到了海德公园，庞涓、孙膑、苏秦、张仪式的高手纷纷走出隐居的鬼谷，在开源舞台上劲舞一支，高歌一曲，用一个个开源项目彰显着自己独特的魅力。
从客户端到数据库，从页面流程控制到业务流程控制，从全文搜索到地图搜索，从论坛到博客，在各种应用领域你都可以方便地找到多个相似的Java开源框架。开源框架的空前繁荣有力的促进了Java技术的交流和分享。一些面向开源的社区，论坛纷纷建立，国内比较著名的就有满江红开源论坛、中文Spring论坛、JavaScud开源平台、JavaEye社区等，宣讲、争论、协作、互动，无数激情和智慧碰撞出耀眼的火花。
随着开源项目的日益增多，国内甚至出现了象open-open.com Java开源大全的汇总整理网站，它如一个开源项目的大集市，将开源项目分类整理，提供简要的描述说明信息，方便使用者了解、查询和比较。
开源项目的繁荣还为技术图书业创造了机会，不管是国外的Amazon，还是china-pub或dearbook，开源框架或产品的技术图书，如Spring，Hibernate，Struts，Eclipse等等都成为荣登榜首的畅销先锋。
这场几乎来源于民间的开源飓风给开发者和CTO们的思路和决策带来了巨大的影响，据Bea的调查，全球排名前2000家软件开发公司中有70%以上在使用一种或多种开源框架——多达28%的公司在开发环境中使用了一种以上的应用服务器。
同时开源也给走传统路线的Java巨头们带来战略性的影响：Sun去年宣布将其旗舰产品——Solaris开源；去年IBM向第三方厂商开放了其高性能通用并行文件系统（GPFS）的源代码；Unisys也改变企业战略定位投入开源怀抱等等不胜枚举，它们纷纷将营利模式从原来的产品销售调整为支持与服务。
2 开源框架带来的烦恼
虽然开源的框架、类库越来越丰富，可供选择的替代者越来越多，但Java程序员却感觉自己慢慢陷入到了技术的漩涡之中：因为他们发现只要一段时间不关注开源社区，就有潮水般陌生的技术框架、专业术语、英文缩略词挟裹着一团团亢奋的热浪将自己淹没，让他们觉得随时都有被Java世界抛弃的危险。许多年纪稍大的程序员甚至觉得职位转换，甩掉技术干管理已经时不我待。
选择的困惑
雨后春笋般涌现的开源框架都声称自己是最好的，有过多次因盲从于技术鼓吹而失望伤心的经历后，现在的开发者都变得成熟理智了，他们不会轻易相信某个框架自身的承诺，不会轻易附和他人的宣传，这确实是件好事。为了作出理智的选择，他们往往要自己亲自摸索以做出评判。
有时，我们会发现向上司推荐一个框架已经变成一件困难的事情，因为上司会冒出各种各样的问题：如Webwork比Struts好在哪里？Hibernate和iBatis有什么区别？OpenWFE比之jBpm有什么优势等等。所以要确定一个框架时，往往需要将相似的框架都研究一遍，以便有充足的理由让上司相信我们的选择是最优的。
但是，要将同类的框架都做一次研究并比较优劣并非易事，如开源工作流引擎就有Willow，OpenWFE，jBpm，Werkflow，OSWorkflow等不下30余种的框架，炫耀的声音一个比一个响亮。每种框架都有自己的设计思路和实现方案，况且这种技术预研性的工作，又不可能在项目周期内占用太多的时间，而不深入预研又不可能客观地作出评判，所以往往是熬红的双眼依然带着迷茫的目光。
此外，用人单位为了减少新员工的培训时间，对求职者往往有明确的框架使用技能和经验的要求。求职者为了能找到一个好工作，不得不逼迫自己学习更多的框架，以便让自己拥有更多的求职机会。
搭配的困难
开源的繁荣虽然给各个领域都造就了许多优秀的框架，如Spring，Struts，Hibernate，Lucene、OSCache等等，但却没有出现一个一站式，统管全局的整合开发框架。开发者在享用大餐之前，事先得充当大橱的角色，将这些盐，油、酱、菜按合理的方式调配好。
虽然，我们一直强调整体大于单个的总和，但是如何将单个“个体”正确的组合成发挥更大效应的“整体”却并非易事。因为这些单独的框架都由不同的团队开发，框架与框架之间存在天然的阻抗，这种框架和框架之间的“代沟”需要额外配置和编码才能弥合。
每个框架都拥有自己的配置文件，框架的整合经常带来配置的灾难，如将Spring和Struts整合时，不仅Struts本身的配置文件一个不能少，在Spring中还需要每个Action提供配置信息，而且两者需要遵守一定的契约。
相互搭配的框架和框架之间经常会出现相似的或重复的功能，如何取舍，如何使用往往让开发者们为难。如Spring本身提供了AOP方法返回结果的缓存功能，而Hibernate本身也提供二级缓存，究竟两者都使用呢，还是择一而从？往往中间又会引出很多争论。
框架整合的问题已经日益突出，我们可以在各开源论坛或社区发现大量有关讨论的主题。目前也出现了一些试图解决的框架整合问题的开源项目，如国外的AppFuse，国内的SpringSide，为框架的整合提供了专业的指导。但是并没有很好的解决现实开发中的实际需要。这些整合框架为了增加通用性，网都撒得太大，导致整合框架本身象一个庞然大物，让人望而生畏，定制性和灵巧性上都存在不足，降低了它们的实用性，所以这些整合性的开源项目往往降格为指导性的实例。
升级的困扰
活跃的框架每天都在升级改造，丰富功能。其次由于开源框架在一定程度上存在随意性，往往导致框架在实际使用后，发现大量隐含的Bug，所以有时对某个框架的升级变得不可避免。开源框架比之Sun正规的规范有着更加灵活的升级方式，高低版本不兼容的问题已经成为司空见惯的事情。如著名的Hibernate，其3.0版本和2.0版本的包名都发生了彻底的变化，刚发布的Acegi和低版本也存在很大的差异，无法兼容。
一个整合性的框架由多个出自于不同团队的框架组成，整合框架在这些组合框架之上高位运行，底层框架的升级变化就造成了组合框架水涨船高的局面，整合框架脆弱的稳定性很容易被打破。
组合框架的升级还直接带来了开发团队学习的压力，为了熟悉框架新功能和改进，在开发工作之余，他们不得不努力压榨自己的业余时间不断地充电学习。总是某个框架新功能学习还未完成，另一个框架的新版本又在一阵欢呼声中闪亮登场，让开发人员发现自己所有的努力只是一场骑牛追马游戏。
3 开发者如何走出迷局
框架的爆炸性增长和技术更替一日千里的速度，让刚刚从传统J2EE迷局中走出来的开发者重新堕入了新的困境之中。有许多切身体验的开发者在网上大倒苦水，甚至有许多声音在呐喊，希望重新回到JSP+JavaBean＋JDBC那个纯真的年代中去。
框架的作者们本想还软件开发一个清新美满的世界，不想个体性的良性企盼变成了一种整体性的混乱纷争。在纷繁复杂的开源世界如何走出迷局和困境，把握自己技术航船的方向，是每个开发者们冥思遐想的事情。
重点学习 触类旁通
每个人的时间是有限的，对于周期紧，进度急，加班赶的开发者来说更加如此，使得开发者不可能 “识遍天下字，读尽人间书”逐个学习框架。选择好适合自己、适合项目的框架进行重点学习尤为重要。不但要掌握技术细节，更要理解框架的原理和思想，这样在接触相关框架时，我们才能触类旁通，慧眼识真。
如果你深入理解了Struts框架的MVC的原理和思想，在接触Tapestry，Spring MVC等框架时，你会发现两者只是形上的区别，而非质上的差异，即使因现实需要确实要转换框架时，也可以轻松平滑地过渡。
不求最好 但求适用
开发人员往往都是完美主义者，吹毛求疵，带着浓重的偏执狂倾向。是的，偏执狂是优秀程序员的一个特点，时下《只有偏执狂才能生存》也正在大卖热卖，Rod Johnson，Gavin King，Oberg也都是偏执狂。
但在有进度工期压力的情况下，我们不得不向实现妥协。对于公司来说，利润永远都是第一位的，不管用不用框架或用什么框架，只要能如期保质保量完成用户的所有功能需求，就是最好的项目。客户永远看不到，也不关心你使用了哪个优秀的技术和框架。
所以，在实际的开发中，也许我们常常需要委曲内心的冲动，只要目前的框架能满足需求，我们没有必须象服装界一样赶追时髦，一切不求最好，但求适用。
如果Spring Template JDBC已经很好的满足了目前的需求，就没有必要一定要上Hibernate，如果自己开发的简要列表控件效果不错，就无须转换为ExtremeTable。新框架的学习需要代价，但这种代价的价值在实际发挥功效之前是不被肯定的。况且看似不合时宜的那些简单而古老的技术也可以做出强大的系统，如世界上最大的java项目——巴西全国医疗系统，就是构建在JSP＋JavaBean＋Servlet之上。
注重积累 搭建平台
我们常常发现一些软件公司自身没有任何积累，完全寄希望于这些整合框架解决所有的问题。开源框架解决的都是某个领域的通用性问题，每个公司由于其所处行业，服务用户的不同，要求公司拥有自己的解决方案，框架的通用性和公司的个性化需求是存在矛盾的。软件公司应该加强自身的积累，在这些框架的基础上搭建好符合自身需求的快速开发平台，屏蔽掉底层框架的复杂功能和细枝末节，降低对开发人员的技能要求，以便新员工能够快速参与到项目中，而无需进行一个个开源框架的学习。
虽然这种积累和平台的建设会耗费额外的工作量，但首先它是一个循序渐进的过程，其次这种任务仅由两三个技术突出的技术人员承担，带来的好处是直接降低了其他开发人员使用难度和技术要求，在一定程序上避免了开源框架的所带来的不稳定性影响。
4 小结
开源的繁荣带来了丰富的框架，有力的推动了业界的发展，同时我们也看到，这种繁荣所带来的惊喜背后紧跟着许多困惑的眼神，迷失在繁荣的混乱之中的开发者们希望走出困惑，走出迷局。
如何在嘈杂喧闹的开源世界把握方向寻求突破，不管是对于开发者还是软件公司的决策者都值得深深的思考。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/824/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
mysql添加用户 alter 语句用法,添加、修改、删除、修改字段存储
freebsd与windows相互传输文件及port安装。评论列表
