原文:EnterpriseRails php?name=Ruby" onclick="tagshow(event)" class="t_tag">Ruby 2006年7月11日 Bliki 索引
摘要:“企业级Rails”这种说法大可视作自相矛盾,但说成“企业级Ruby”就是两回事了。核心Rails窄小集中,而Ruby世界(包括Rails)宽广发散——持这种观点可以做到不偏废,其精髓就是小巧工具结合起来威力无穷。Rails已明确了自己的取向,留下的缺口将会由别的框架填充,而Ruby正是一片适宜这些框架发芽、成长的绝佳土壤。Ruby这种不会僵住的胶水语言似乎正是用以迎合企业应用发展趋势的理想工具。
在新形成的Rails社群里,“企业”这个词正在变成一个禁忌字眼。很多人认为,Rails框架因为它激进的简洁性,锋芒毕露,树敌无数,成为那些“企业级超复杂”框架们的对立面。
在最近召开的Rails用户大会——RailsConf上,PragDave的开场主题演讲重点列举了Rails没有解决的一些议题,其中一部分说的就是这些“企业级超复杂”问题,例如,他呼吁让Rails支持更复杂多样的数据库结构(如复合主键等)。
DHH对此的回绝简直干脆地不能再干脆了。不久前那期《连线》杂志上,DHH作为封面人物的图片做了精细的视效处理,他让自己化身为软件世界里的Neo,不容置疑地昭告天下自己身处光明的一方,喝令企业应用世界的人都编入他的麾下,切莫弃明投暗。支持复合主键——他的回答是“没门儿”。Rails会沿着自己的路走,不会因为那些不爽的东西给自己添累赘。
David Heinemeier Hansson (DHH) Neo Dave Thomas (PragDave)
Rails天生一副倔脾气,来看个能充分证明这一点的例子吧:如果你依随Rails的习性,让数据库表跟对象保持同构,给表加上整型主键来唯一指代对象,你的生活将简单而美好。只要照Rails的规矩办事,一切轻松搞定;否则,一切免谈,找别的框架去吧。
我承认我喜欢这种倔脾气,这或许反映了我的Unix背景,Unix里有丰富的工具,它们每一个都只作一件事,并把这件事做好,都不是试图解决多种不同问题的庞然大物。我喜欢Rails的这份专注,喜欢它果断地选定一类应用并处理地漂漂亮亮。
从这儿说开来,我发现DHH和KentBeck有种惊人的相似之处。在一个充满限制的世界里,我们觉得那些限制天经地义,而他们俩就能把那些限制看成是多余的,开创一个没那些限制的新世界。我没有这份天赋,我倾向于费劲地扛着限制的重压慢慢往前走,而他们能凭借自己的智慧来一招金蝉脱壳大踏步前进。这就是他们之所以能创造出“极限编程”和Rails这种震憾整个行业的东西的原因。
其实PragDave演讲的背后有更深层的考量。他和我一样,这辈子多数时间的工作伙伴是那些无法施展金蝉脱壳的人。比如一个数据管理组织的某个数据库已经跑了十来年了,你要访问里边的数据,但它偏偏用了复合主键——你哪还能带上副很酷的墨镜然后说“不用理那些限制”?解决办法有二:“要么改变这个组织,要么脱离组织(另谋高就)”,若这二者都做不到,是不是就彻底搭不上Ruby这班车了?
问题的关键就是上句话里那四个字母——Ruby。我认为Rails对企业级超复杂的东西视而不见是明智的,但并不是说Ruby也应该那样。软件生态系统已混乱不堪,像Ruby这样的脚本语言以后现代主义的睿智兴奋地跃身其中,这正是它们强大的力量所在。Rails已明确了自己的取向,留下的缺口将会由别的框架填充,而Ruby正是一片适宜这些框架发芽、成长的绝佳土壤。
我的同事Badri做了个演讲,遗憾的是我没能详细听,主题就是这类框架之一——rBatis。rBatis是流行的Java框架iBatis的ruby移植版,iBatis由我的另一位同事Clinton Begin领军,我的第三位同事Jon Tirsén是rBatis的始作俑者。尽管rBatis目前还在开发之中,但它已经体现出了和前辈iBatis相同的流行气质——不是用Query对象层竭力掩藏SQL,而是大胆地拥抱SQL自身的强大。另外,rBatis还充分利用Ruby语言来提升自己的魅力指数:奉行拿来主义,用了大量ActiveRecord的功能(例如合法性验证);落实实用主义,取Ruby语法之便而弃用XML。(XML像不像编程语言的赘瘤?)前边说的那些复杂的数据库问题,可以用rBatis解决,再整合到一个RailsWeb应用中,只是这样做会引入另外一系列利弊权衡。假如你觉得SQL好用,那rBatis对你来说就是小菜一碟。(顺便插一句,有没有Ruby粉丝在悉尼?要是rBatis的开发进展慢下来的话,我们需要你设法夺走Jon的冲浪板)
所有这些都扯动我们的视角。“企业级Rails”这种说法大可视作自相矛盾,但说成“企业级Ruby”就是两回事了。企业应用世界在朝下面几个方向发展:越发重要的消息机制,以服务自主自治为特点的应用式数据库,后现代式的对多元化兼容并包——这是我持续的观察分析所得出的观点。Ruby这种不会僵住的胶水语言似乎正是用以迎合这些发展趋势的理想工具。
尽管一些人觉得这些演讲暗示出两位David的思路出现了裂缝,但进一步的谈话让我体会到:任何裂缝的出现都源自误解(我开始用乱弹式的隐喻了)。PragDave并不是希望Rails支持这些东西,而是呼吁范围更广的社群来给出解决方案。同样,DHH对他的回应只是针对Rails核心团队说的,不会捆住别人的手脚,rBatis就证明了这一点。再说,DHH也承认PragDave的多数提法与Rails核心团队的理念是相符的。核心Rails窄小集中,而Ruby世界(包括Rails)宽广发散——持这种观点可以做到不偏废,其精髓就是小巧工具结合起来威力无穷。
然而,这种Ruby宽广Rails窄小的视角也不尽完美。在我的主题报告上,我开玩笑说RailsConf的存在就证明了Rails的失败——假如Rails真那么成功的话,它应该简单得不得了,哪还需要什么讨论会呀?但是,Rails已成为Ruby在Web应用乃至企业应用里的王牌框架,这是个不争的事实。我怀疑在RailsConf比在RubyConf能看到更多关心“超复杂企业级”的人,因为Rails已经成为了吸引眼球的焦点——这会带来一个危险:人们可能会误以为Ruby也像Rails一样天生一副倔脾气,心里留下个印象:“Ruby不是种合适的企业应用胶水”——果真如此,就太遗憾了。