我怎么就觉得rails适合做大型应用

    之前读了不少文章，说rails不大适合做大型的互联网应用或者企业应用，但通过实际的使用rails，越发的发现rails做大型应用是个不错的选择。 说rails不适合做大型应用无非瞄准了rails的2个软肋，一个是ruby的性能，一个是后期的可维护性。 

    先谈谈可维护性吧，可维护性最大的问题是需求的改变，简单的说，取决于项目结束后，客户要求你变更程度的大小与多寡，这更多的是项目管理的范畴，具体到语言的层面，其实意义不大，我们可以想想，一个后期维护的问题放到rails难解决，那么放到java、php……里面就简单了？真要比个优劣的话，我倒是觉得rails更胜一筹，rails本身就是一套良好实践的集合，你按它的规范做，会少走不少弯路，与其说rails是框架级代码的复用，不如说是良好设计和经验的复用。

    咱好好谈谈性能吧，由于rails是个全栈式MVC框架，各个组件之间的搭配都是经过优化的，而采用SSH，需要自行协调各个组件之间的协同工作，稍有不慎，肯定会带来性能上的问题，我想各位看客也知道那个意思，我这里就有个例子，一个用SSH开发的社区网站，速度极其的慢，采用ruby on rails 改版后，速度明显提升很多，当然这可能也和开发者的水平有关，我也懒的去研究为什么当初采用SSH时性能会出现瓶颈，仅仅这个例子，让我知道一个一般的程序员用rails开发出东西未见得比用SSH的东西性能要低。

    当然，上面的例子可能并不具有普遍性，所以说服力也不够。那么总所周知的是，做一个大型应用的杀手锏是“分”，当年的j2ee也是这种理念，尽可能的分，但遗憾的是j2ee分的效果并不太好，或许是过于复杂了，我所知道的java项目大都跑在一台服务器上。当然也是有很多大型java项目还是分布式的，那么既然大家都跑在多台廉价的服务器上，单纯的比单台服务器的速度其实意义并不大，在一个可伸缩的架构中，资源的消耗应该随负载线性上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。

    所以问题归到了架构上面来了，而对于目前或者未来的应用架构，最合理的方式是把一个大型应用拆成许多合理的单元，而内置了REST支持机制的rails将抢占了未来的先机，当然可能这种机制尚不完善，但它的方向我认为是正确的。

那么我对rails的"分"的方案有以下几种思路：

    1 在应用程序的之间水平切分，一个系统拆成各自独立的系统拼接而成，每个独立的系统的后台将做服务器级别的集群，举个例子，校内最近开发的爱听网就是用ruby on rails 开发的，它将是个独立的系统，会作为一个频道拼到现有校内的菜单上，这种方式不错，但相互过于独立，数据共享是个问题。

    2 在应用程序的内部水平切分，这种粒度要小一点，做相册的负责图片，做音乐的负责音乐，做博客的负责博客，用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以选择自己的应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。貌似豆瓣是这种模式。

    3 针对具体资源的切分，这种方法是把所有的服务抽象成粒度更小的资源，分布在各个服务器上，在主服务器上通过REST调用展现出来，这样各个服务节点相互独立，不会因为某一节点造成性能上的瓶颈，当然我也不是随便说说，目前准备用这种方式构建一个社会化网络，就目前的感觉---良好。

    4 SOA，相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你是否把它叫做SOA，功能分解还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。我对SOA理解不深，这里有一段访谈倒是蛮有说服力,

 

 

 

 

 

 

 

写道

Engine Yard公司的首席技术官Tom Mornini表示，单机百万线应用的时代已经结束，面向服务架构(SOA)是这一时代的终结者。该公司提供Ruby and Rails主机服务器。
　　他在最近的采访中说“我认为使用大型程序的年代已经结束了”“有些程序看起来很大，但是随着时间的推移，它们将最终成为许多小程序的结合体。”
　　通过为全球市场的业务提供灵活性，SOA的可组合性改变了应用开发比赛。在全球市场中，商业机会不是一成不变的。
　　Mornini说“我实在看不出任何其他方式可以满足存取数据，改变流体的需求，以便在企业内外跟上时代的步伐。”“这就是为什么未来能解决所有问题的单机百万线应用在这一点上仅仅是个遗迹。”
　　Mornini认为，这不再是SOA是传统应用开发选择的问题，而是除了SOA以外，我们没有其它的选择。
　　他说“这些大型程序很难管理和维护，很难想像单机应用会成为未来发展的方向”。
　　Engine Yard公司的首席技术官认为带有REST的Ruby on Rails是为SOA建立新一代的服务和应用的一种方法。与Java不同，Java是在SOA应用开发时代前开发的项目，他注意到，Ruby on Rails 和REST怀抱SOA为理念向世人提供了一个前所未有的方法。
　　Mornini说“拥有一个服从该框架的牢固而又深厚的面向服务架构就是Rails的秘诀”该架构的开发商认为（它的SOA功能）是该平台的一大优势。
　　他认为Ruby on Rails非常适合SOA开发。新发布的Rail 2.0令该框架更容易为SOA应用以及旧数据存取所接受。他承认，原有的Rails框架与旧数据存取关系并不是十分融洽。今年推出的新模型已经超过了前者。
　　他说，例如，Rails组提供的代码增加了许多新的功能，通过以服务的形式将旧数据曝光，使得在SOA应用中访问旧数据变得更为简便。
　　Engine Yard公司的首席技术官说 “由于遵循了售后服务书籍和网络视频记录的规程，Rails令开发商使用RESTful数据变得更为简单”。
　　他说，“如果你遵循RESTful Rails的标准过程，在系统外用Rails编写了一个程序，就会自动得到该程序展示的一个建立在XML-over-HTTP基础之上的API。
　　但是如果要使其运转，"继续使用 Rails"很重要。Mornini说这就是Rails遵循既定规程的妙招。

 

 

 

 

 

评论

234 楼 pufan 2008-08-27  

重视人机交互没什么错，在我看，可用性与易用性取舍，属于两手都要抓两手都要硬。

哪些说人傻的要慎重，没准人家比你聪明。

233 楼 hideto 2008-08-27  

自从liusong1111之后本帖就开始变成消遣贴了～～
你的头像mm咋只有两个指头？
最后一句改为“不知道Itian是装疯还是卖傻”更有幽默感

火星叔叔马丁 写道

对于一个企业应用，良好架构，良好设计重要性居然不如你所说那几个V？
况且这些v和rails无关，你用RIA实现，我就不能在前台用RIA了

不知道Itian是装傻还是卖傻

232 楼 花花公子 2008-08-27  

只见V字仇杀队乱舞……还是闪吧

231 楼 jack 2008-08-27  

ltian 写道

不做WEB应用还ROR个头，Delphi，CBuider，pb，大量地企业应用到现在还是这些语言和工具的天下，哪个不是比现有所有这些WEB技术的开发效率高啊。如果你们不服就找他YY去。

有没有统计数据来证明你这个观点？我想看点实际的证据。
另外 什么叫 “企业应用”可不可以给个定义？ 这样讨论连基础都没有哦。

230 楼 风清云淡 2008-08-27  

liuqiang 写道

to pufan:
关于这个的讨论可以见: http://www.iteye.com/topic/82227 , 这个话题里本不该讨论这个撒。


to 风清云淡:
dlee上次说他们目前用pureMVC+rails+rest感觉很好，另外印客网貌似也有flex+rails的产品，那个校内也是准备用flex+rails打造一个音乐互动平台，我们最近准备上个flex+rails项目，有时间可以交流下。

另外不要过分打击别人，人急了是要骂街滴：）

我是用Grails，没用rails。虽然有n年的C++和JAVA经验，但是对动态脚本语言还是刚入门，不过现在觉得很好玩。就像04年我从C++转到java的感觉。

现在用flex+pureMvc+rest+grails这个技术路线做系统，还是靠忽悠把老板给蒙了， 。
我这纯粹是玩技术，不过还好这个项目是非市场项目，成败关系不大，全当demo给兄弟们练手，也算多学门混饭的手艺。

等过段时间，项目进展的差不多了，大家可以多交流一下。

229 楼 心无旁骛 2008-08-27  

这种讨论有意思么？各个笑里藏刀，恨不得把人踩脚下还要装斯文

228 楼 风清云淡 2008-08-27  

ltian 写道

风清云淡 写道

引用

1Tian老兄，你犯了大忌啊，不懂的东西，不要乱发意见，容易出洋相啊！<color=red>俺是不懂的从来不说</color>，毛老人家不是教导过我们，没有调查就没有发言权！

多做、多实践，多听、多想、多分析、多总结，等有经验和水平了，就可以充“权威”了，

你让gigix出来说话吧。他不是你们心目中的“权威”吗？你们的权威告诉你们，分布式的企业应用系统就不该用浏览器做客户端。没有浏览器的还叫WEB应用?不做WEB应用还ROR个头，Delphi，CBuider，pb，大量地企业应用到现在还是这些语言和工具的天下，哪个不是比现有所有这些WEB技术的开发效率高啊。如果你们不服就找他YY去。

奇怪，你不懂怎么知道别人说的就有毛病呢？好好翻翻贴，然后把我说的那个V开发出来再教训人也更有说服力。

唉，叫我怎么说呢？你怎么不看看我的帖子，我选择了什么方案？
呵呵，gigix不是俺心目中的“权威”，你别激动。我说这些实在是好意，你不领情，我没辙了。

不过一个没用过ror的人(用JAVA)和一个有ROR和JAVA实践经验的人辩论一个以ror为核心的话题，我怎么老觉得哪儿不对劲了？

227 楼 pufan 2008-08-27  

liuqiang 写道

to pufan:
关于这个的讨论可以见: http://www.iteye.com/topic/82227 , 这个话题里本不该讨论这个撒

嘿嘿，有感而发，这年头，谁也不比谁懂的多多少。

分布式系统是怎么定义的，google一下就清楚，传输个所谓的“分布式对象”就是分布式系统了吗。

还有那个通讯第一原则更是扯，按我看第一原则是减少传输量，网络传输的最小单元是bit，文本又是什么东西。

226 楼 liuqiang 2008-08-27  

to pufan:
关于这个的讨论可以见: http://www.iteye.com/topic/82227 , 这个话题里本不该讨论这个撒。


to 风清云淡:
dlee上次说他们目前用pureMVC+rails+rest感觉很好，另外印客网貌似也有flex+rails的产品，那个校内也是准备用flex+rails打造一个音乐互动平台，我们最近准备上个flex+rails项目，有时间可以交流下。

另外不要过分打击别人，人急了是要骂街滴：）

225 楼 pufan 2008-08-27  

gigix 写道

ltian 写道

gigix 写道

引用

我没说rail不能支持RIA.你自己理解问题。webORB和rubyAMF这两个东西的存在我知道，但不感兴趣.成功的案例有多少我不知道，但是java与RIA组合成功范例太多了。

这个，太可爱了
既然你做RIA嘛，前端后端本来就是两大块，中间XML或者JSON
那就算一个成功案例都没有吧，可是你在担心什么呢？
担心Rails生成不了XML？貌似这个风险小得很啊。
还是担心你做的RIA前端他只能解析Java生成的XML，解析不了Rails生成的XML？

我说，有风险意识是好事啊，没事瞎操心那跟风险意识还是有点区别的吧？

呵呵，针对你这个回帖我忍不住回一下,你java+RIA不太了解，用XML传送数据给RIA性能，开发效率都不好.
在JAVA+RIA的系统用XML传送数据的方案我们团队考虑过,不太现实.很多人说hession可以作java何flex之间的桥梁，但是我发现有问题。很多东西不是说理论上能够实现的就一定可以用在企业开发上。要去试。
我们使用Java+RIA的系统开发中，java和flex之间传递数据是通过客户端的虚拟机AVM对象与服务端JVM对象之间的序列化与反序列化完成的。

我就说嘛，果然是个很可爱的方案啊
分布式系统第一原则：不要分布对象
通信第一原则：使用基于文本的协议
一下子违背这么两个原则，当然了你一定是理由充分的啦，不过，请继续保持高风险意识吧，你还有得操心呢

真xx能扯，不愧为作咨询的呀，难道TWer都这样？


客户：想要设计一管理系统，多人访问，BS架构怎样？
TWer：走BS就要传输HTML，按照分布式系统第一原则，这就是“分布对象”了，建议你们设计成单机版。

客户：那数据怎么共享呢？
TWer：共享那还不简单，本机操作完同步复制到其他机器就行。

客户：果然是好办法，那通讯协议怎么定，走java序列化怎样，编程简单。
TWer：不行，按照通信第一原则，要“使用基于文本的协议”，可以参考http、tcp、ip、arp、3p，你要这样...那样...

客户（无比敬仰的表情）：知识渊博呀，下次顾问还找您！

224 楼 风清云淡 2008-08-27  

引用

1Tian老兄，你犯了大忌啊，不懂的东西，不要乱发意见，容易出洋相啊！俺是不懂的从来不说，毛老人家不是教导过我们，没有调查就没有发言权！

多做、多实践，多听、多想、多分析、多总结，等有经验和水平了，就可以充“权威”了，

223 楼 风清云淡 2008-08-27  

我没有用过ruby和ror，看了很多人的评论，对ror还是不太放心。
目前正在鼓捣一个系统：flex+pureMVC+rest+grails，选择grails是觉得这个东东在JAVA框架和ror之间做了一个平衡（呵呵，我比较倾向中庸之道），毕竟groovy背靠JAVA这个笨重而稳定的大树。
我比较推崇实践主义，如果没有实际大型项目经验，还是保守点。
不过个人目前比较忙，有时间也鼓捣一下rails，做个实际的系统，等有经验了，再和各位讨论一把。

闲话一把：
1Tian老兄，你犯了大忌啊，不懂的东西，不要乱发意见，容易出洋相啊！俺是不懂的从来不说，毛老人家不是教导过我们，没有调查就没有发言权！
《应用Rails进行敏捷web开发》快看完了，就是上面的例子太easy 了，唉，要是以后的书弄厚一点，弄一个实际项目的案例，就会少很多顾虑和争执了。

222 楼 cquaker 2008-08-27  

<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>Craft 写道</div>
<div class='quote_div'>我们公司打算安排5个人用rails &amp; ruby做ESB和BI这样的大型应用。这套系统将承载至少5省电网数据的交换、分析和展现，也会逐渐加上各种业务功能。 <br/>ESB打算用ruby写，听说开发效率比java更强，新版本已经接近c的性能了，稳定性需要保障全年不间断运行。系统要承载数十个电力系统的数据交换业务，考虑使用集群、自动路由等功能。 <br/>BI的ETL/OLAP部分用ruby写，报表展现和决策分析部分用rails来做。功能上就是几百个的图表的实时展现，用户数在5万左右。 <br/>大家给点意见顺便帮评估一下，5个人8个月应该可以完成吧？</div>
<p> </p>
<p> 我感觉前期的需求一定要做好，之后就是设计，设计出来后，用rails开发起来很快的，所以花多点时间做设计是值得。</p>
<p> </p>
<p>报表展现和决策分析能否交给Oracle做？</p>
<p> </p>
<p>我去年年底，用rails抢做了一个项目，由于比较急，是个政府OA系统，准备年前上线，算是形象工程，3个人，不算是经验丰富的，花了2个月，好在需求没怎麽变。</p>
<p> </p>
<p>我个人觉得8个月是足够的。</p>
<p> </p>
<p> </p>
</div>
<p> </p>
<p>    liuqiang说的有道理，不是ruby和rails强项的东西，各归其主，交给其他擅长此功能的模块实现好了，这样就不会越俎代庖了。</p>

221 楼 liuqiang 2008-08-27  

<div class='quote_title'>Craft 写道</div>
<div class='quote_div'>我们公司打算安排5个人用rails &amp; ruby做ESB和BI这样的大型应用。这套系统将承载至少5省电网数据的交换、分析和展现，也会逐渐加上各种业务功能。 <br/>ESB打算用ruby写，听说开发效率比java更强，新版本已经接近c的性能了，稳定性需要保障全年不间断运行。系统要承载数十个电力系统的数据交换业务，考虑使用集群、自动路由等功能。 <br/>BI的ETL/OLAP部分用ruby写，报表展现和决策分析部分用rails来做。功能上就是几百个的图表的实时展现，用户数在5万左右。 <br/>大家给点意见顺便帮评估一下，5个人8个月应该可以完成吧？</div>
<p> </p>
<p> 我感觉前期的需求一定要做好，之后就是设计，设计出来后，用rails开发起来很快的，所以花多点时间做设计是值得。</p>
<p> </p>
<p>报表展现和决策分析能否交给Oracle做？</p>
<p> </p>
<p>我去年年底，用rails抢做了一个项目，由于比较急，是个政府OA系统，准备年前上线，算是形象工程，3个人，不算是经验丰富的，花了2个月，好在需求没怎麽变。</p>
<p> </p>
<p>我个人觉得8个月是足够的。</p>
<p> </p>
<p> </p>

220 楼 Ashela 2008-08-27  

ltian 写道

hyf 写道

强啊！无敌啊！

ltian兄，我很喜欢你。就为你对V的重视，我觉得你很有魅力。

我在这里被批判的较多，我都没有能力鉴别你说的话是正面还是反面。V对于企业应用来说很重要，V不方便用的时候，用户是不会喜欢这个系统的，任凭你服务器端做得多么好，用户不认可。当然没遇到这种情况的人是不了解的。被用户骂烂系统的滋味并不好受，甚至会感到很委屈。因为在系统的构架，代码的质量上花了很大的功夫，得到的是不认可。多年血教训告诉我，V很重要。

V是很重要，但我觉得没有重要到比业务领域模型和架构更重要的地步

219 楼 rubynroll 2008-08-27  

liusong1111d对“话题2：通用框架和组件的能力”的阐述堪称精辟，无懈可击。而恰恰这一点是很多人所误解的。

有些‘大牛’经常会发出这样的感慨“语言不重要，重要的是XXX架构，XXX思想...”，是的，对于那些手下都是些项目经理的人来说，技术都不重要了，何况乎编程语言？

语言真的不重要么？当然重要。这并不是说编程语言可以任意替换，有些场合下是没有选择余地的，例如仅有几十个byte内存的MCU，但是大多数场合下，是有相当大的选择余地，可以互相取长补短。

语言带来的效率提升和思维变化，是不应该被忽视的。Ruby,Python,Erlang这些语言被推崇并不是无风起浪，各位看客真的应该再读一读以下这些文字：

liusong1111:

引用

语言、库（组件）和框架的大致关系：

语言1 < 技术基础库(组件)2 < 技术基础框架3 < 业务基础库(组件)4 < 业务基础框架5 < 业务应用代码6

靠前的是后面的基础。VM、IDE属于它们之外的切面，不在这一话题谈论范围内。

靠后的东西，可以利用它前面的全部东西。比如，业务基础库可以使用语言、技术基础组件库、技术基础框架。

我们开发一个系统，对于1,2,3多会选择一个现成的适合自己的，对于4,5，可能选现成的，也可能自主开发，或兼而有之。
对于6，不可避免的要自主开发。

一般认为，基础性的东西越强，上层的东西越彪悍。所以，语言不是无关紧要，而是很重要。它的强大，可以影响到后面所有层的能力。

即使我们假定所有可封装的都封装到了前5层，那么，业务应用代码还是需要我们利用语言把2,3,4,5组合起来完成特定的业务功能。这个组合行为，是发生（并且应该发生）在第6层的，你不可能再通过封装等手段，把它压到前面的层次。说极端了，假如所有东西都能往上一层压（封装），那就不存在业务应用层了。我们大部份人现在所做的就毫无意义，即将失业了。

当然，前面假定各个层的设施是完美的。
对于ruby组件/库、框架的现状（数量、领域、成熟度、稳定性等），robbin和其它人都有讨论，下结论前多看看。
我同意gigix以前的看法，选择某个领域的框架、库，好使的，一个就够了。一堆烂东西加一块还是烂。

另外，由于前面的图示，语言的能力，也可以提升组件/库/框架的能力，使得建立在其它语言之上的同领域产品，一些能力根本不可能达到。
比如，用java就不可以做出ruby的ActiveRecord库同等能力的东西，不论是hibernate还是你自己从头编起。

这里的能力，指“抽象”或“封装”的能力，不是指“原始能力”。

所以，结论是，大型系统靠的既是业务框架和组件，也有通用框架和组件，也有语言，他们共同的能力，来缩短代码行数，来提高系统的稳定性和易维护性。不止是语言本身，但语言也是极为重要的。

218 楼 cquaker 2008-08-27  

Craft 写道

我们公司打算安排5个人用rails & ruby做ESB和BI这样的大型应用。这套系统将承载至少5省电网数据的交换、分析和展现，也会逐渐加上各种业务功能。
ESB打算用ruby写，听说开发效率比java更强，新版本已经接近c的性能了，稳定性需要保障全年不间断运行。系统要承载数十个电力系统的数据交换业务，考虑使用集群、自动路由等功能。
BI的ETL/OLAP部分用ruby写，报表展现和决策分析部分用rails来做。功能上就是几百个的图表的实时展现，用户数在5万左右。
大家给点意见顺便帮评估一下，5个人8个月应该可以完成吧？

我说出来可能大伙都不相信，某大型水电站的系统用asp实现的，还是很多年前完成的，我看那帮人现在用起来没觉得有啥不爽的，应该比你的这个复杂，不过可不是5个人8个月搞出来的，十几个人几年驻扎在现场搞的。


新版本已经接近c的性能了？  这个从来没听说过。

217 楼 Craft 2008-08-27  

我们公司打算安排5个人用rails & ruby做ESB和BI这样的大型应用。这套系统将承载至少5省电网数据的交换、分析和展现，也会逐渐加上各种业务功能。
ESB打算用ruby写，听说开发效率比java更强，新版本已经接近c的性能了，稳定性需要保障全年不间断运行。系统要承载数十个电力系统的数据交换业务，考虑使用集群、自动路由等功能。
BI的ETL/OLAP部分用ruby写，报表展现和决策分析部分用rails来做。功能上就是几百个的图表的实时展现，用户数在5万左右。
大家给点意见顺便帮评估一下，5个人8个月应该可以完成吧？

216 楼 liping 2008-08-27  

gigix 写道

ltian 写道

这里面的功能都以数据库记录增删该为主，简单界面工作量相对大，做简单WEB界面是Railde强项。
如果我让你做企业应用界面恐怕你就累死了，再让你用Rail实现电力、通信、银行的业务逻辑，恐怕也没那么容易了。
这个系统无法代表大型企业应用，只能代表论坛类网站的开发。

瞧瞧，又是这种调调
&ldquo;我们的东西很牛x的，你这些小花招在我们这里根本行不通&rdquo;
&ldquo;我们情况最特殊了，你们那些东西太理想化，不适合我们的情况&rdquo;
听得我都烦
告诉你两个事实，第一JavaEye的功能显然不是数据库记录增删改为主，第二企业应用我们用Rails做了好多了
信不信随便啦

   gigix 你们的企业应用使用Ruby 还是JRuby的 能不能新开一个帖子讲讲这方面的情况啊！

215 楼 liping 2008-08-27  

<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>liping 写道</div>
<div class='quote_div'>J2EE发展这么多年 比ROR更加成熟吧！在企业计算方面。j2EE的稳定性,成熟度,资源等等比ROR更好.ps..性能和维护更多的是有人的因素。</div>
<p> </p>
<p> 稳定性,成熟度,资源，这也是J2EE最后的一块遮羞布，要比这些我更看好MFC，结果世道变了，MFC的稳定性,成熟度,资源已是昨日黄花。</p>
<p> </p>
<p>最近校内采用rails+flex开发新的系统，我拭目以待，至于兼容性我想每个语言都有，相对于php从4-5，我觉得rails要好多了。</p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p>      还有一个是JAVA社区要比RUBY(ROR)社区大。MFC现在应该是小众了吧！ 昨天 -今天 -明天 这是永恒的话题。语言也是,框架也是,明天的Ruby(ROR)或许就是今天的JAVA(J2EE)。现在的java包袱大多了！希望ROR不要有太多包袱(当然放下包袱快速行进的时候不要忘了兼容性)。贪心永远只是空想...没事十全十美的事。</p>