我怎么就觉得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遵循既定规程的妙招。

 

 

 

 

 

评论

194 楼 gigix 2008-08-26  

ltian 写道

连什么是分布式系统都不认识的人,怎么去给别人做咨询,我也很难想象.不要故作高深的笑.,RIA+JAVA开发的企业应用,怎么成的分布式?你的原则又怎么适用了?你说清楚了在笑好吗?大家都在睁眼看着呢.

看看，本来我都不知道该说什么才好的，端一杯茶在那一放，自己就冒出来了
RIA+JAVA开发的企业应用，我也不知道它怎么就成了分布式的呢
感情你们用户都直接跑到数据库服务器上去用啊
果然是了不起的大型企业应用呢

193 楼 wgq0319 2008-08-26  

看了半个多小时，楞没看完。愿意用什么就用呗。谁给钱多给谁干，让用啥用啥。

192 楼 gigix 2008-08-26  

ltian 写道

连什么是分布式系统都不认识的人,怎么去给别人做咨询,我也很难想象.

 
要这样子的继续看下去

191 楼 liuqiang 2008-08-26  

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>兄弟别卖弄你的课本知识,我也不喜欢你这种嘲讽人口气.这种序列化与反序列化的框架有hession和adobe的BlazeDs，你去告诉他们你的原则，然后嘲笑他们一番。</div>
<br/>早料到你不信，没关系，你是对的，你当然有充分的理由这么做咯，我就随口瞎说的，别当真 <br/>毕竟那是你每天在上面工作的系统，又不是我的，你又不付钱给我做咨询 <br/>顺便说，看到你这么重视大型系统的架构，真的，那真的非常有必要呢</div>
<br/><br/>让你做咨询的人都办都是被忽悠的吧。</div>
<p> </p>
<p> 大哥，你怎么出尔反尔呀，咋又开始淌混水呀，gigix明显是拉你下水，呵呵，你太可爱了，所以会上当</p>

190 楼 dempire 2008-08-26  

gigix 写道

ltian 写道

兄弟别卖弄你的课本知识,我也不喜欢你这种嘲讽人口气.这种序列化与反序列化的框架有hession和adobe的BlazeDs，你去告诉他们你的原则，然后嘲笑他们一番。

早料到你不信，没关系，你是对的，你当然有充分的理由这么做咯，我就随口瞎说的，别当真
毕竟那是你每天在上面工作的系统，又不是我的，你又不付钱给我做咨询
顺便说，看到你这么重视大型系统的架构，真的，那真的非常有必要呢

这几天在某地好心希望某些程序员面对自己的缺点改变自己，结果遭到各种板砖，我终于明白了，为什么有高低贵贱，贫富忠恶，就是因为人不一样，思想也不一样，如果人人都能掌握真理，大家就都成了高手了，所以，不要总是想办法劝人从善了，当个笑话一笑了之，反而让自己轻松些…… 

189 楼 gigix 2008-08-26  

ltian 写道

gigix 写道

ltian 写道

兄弟别卖弄你的课本知识,我也不喜欢你这种嘲讽人口气.这种序列化与反序列化的框架有hession和adobe的BlazeDs，你去告诉他们你的原则，然后嘲笑他们一番。

早料到你不信，没关系，你是对的，你当然有充分的理由这么做咯，我就随口瞎说的，别当真
毕竟那是你每天在上面工作的系统，又不是我的，你又不付钱给我做咨询
顺便说，看到你这么重视大型系统的架构，真的，那真的非常有必要呢

让你做咨询的人都办都是被忽悠的吧。

越来越显得可爱了呢

188 楼 gigix 2008-08-26  

引用

1 我知道SOA可以在网上搜得到大量文章，但我却不知道在ava中如何SOA，我的看法和"readonly"一样，只见SOA嗡嗡嗡，当然你可以举实际的例子来反驳

通常你先有一大堆乱七八糟的应用程序甚至信息孤岛
而不是正在打算做一个”大型企业应用“

187 楼 liuqiang 2008-08-26  

<div class='quote_title'>starfeng 写道</div>
<div class='quote_div'>
<p> </p>
<p>1. REST<br/>SOA可以在网上搜得到大量文章，就REST这个通信部份，我就说一下：<br/>通常的项目中用不到，但当项目较大时，会遇到.Net和java的通信，老版本j2ee平台和新架构（比方spring，只是比方）的通信，这里老的项目支持某一种或两种协议，这时，你要调取别人的服务就得用别人能懂的协议，虽然，REST不错，但你这里无法对老的系统全改为REST，代价大，风险大。也许你会说，针对每种协议写一个Adapt就可以啊。是的，是一种方法。SOA（有很多轻量级open source的SOA，不一定非要用钱去买）对你说，你不用写了，我帮你写好了。<br/><br/>2. 太多太多的东西<br/>一是指各种component，像我们平时用的各种apache library，各种j2ee中提及到的服务（像tx, mail, jms等等）。rails在这一部份很缺少，虽然他的component在不断增长，但相比java，太少。<br/>二是指解决方案，方案这东西，不能保证你快，但他能保证你的安全，性能。上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应。rails在这一部份很缺少，你得在定方案前做各种检验。<br/>三是指兼容性与集成性，全新的东西是好办事，但你不能让企业把它运行得好好的东西全部重新开发吧。那么怎么集成，如何平滑的升级，这里又是一堆要做的东西。rails在这一部份也没怎么见过。<br/><br/>3. 轮子<br/>关从技术角度，.Net还真是这样。但从商业角度，从兼容性等方面来看，那就不是了。<br/><br/>4. 开发速度<br/>的确，j2ee的方式是慢，看上去java比不上rails，但是，这个问题要看架构师如何设计你的架构，如何利用或改装现有组件。思想是相通的，rails代表的是思想，而这种思想在java上实现是一样可以做到的。<br/><br/>5. 欧美项目<br/>我知道瑞士银行的一个核心项目也在用SSH（非门户之类，涉及到具体投资、资金方面），这句话好像有点抬杠，我主要是说，在面对新兴的技术，其实是有各种选择。rails最大的问题是优势不明显（从架构的角度），底气（component,项目证明等）又不足，所以现在不是它用于做大型应用的时候。</p>
</div>
<p><br/>你说这个很有讨论的价值</p>
<p> </p>
<p>1 我知道SOA可以在网上搜得到大量文章，但我却不知道在ava中如何SOA，我的看法和"readonly"一样，只见SOA嗡嗡嗡，当然你可以举实际的例子来反驳</p>
<p> </p>
<p>2 tx, mail, jms 在ror中是有的，数量不多是事实，属于最小实用主义，个人认为不见得就差，当然你得充分理解最小实用主义。</p>
<p> </p>
<p>3 方案 “上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应，rails在这一部份很缺少，你得在定方案前做各种检验”，这个我不好说，但 TW应该有大量的一手经验</p>
<p> </p>
<p>4 轮子，虽然JE做.net的比较少，但这样说微软有点不厚道了吧：）</p>
<p> </p>
<p>5 架构，对REST的拥抱是个很积极的举措，至于你说的那个是遗留项目，我在主题贴已经强调了这个是rails的弱势，java刚出道时，去兼容老系统比这种情况更加那个什么</p>
<p> </p>
<p>6 另外，我说rails适合做大型应用，并不是说java就不适合，rails能做，java基本都可以做，这是事实，我承认。或许我们可以从开发效率以及后期维护再以及对rest的原生态支持上探讨下<br/></p>
<p> </p>
<p> </p>

186 楼 gigix 2008-08-26  

ltian 写道

兄弟别卖弄你的课本知识,我也不喜欢你这种嘲讽人口气.这种序列化与反序列化的框架有hession和adobe的BlazeDs，你去告诉他们你的原则，然后嘲笑他们一番。

早料到你不信，没关系，你是对的，你当然有充分的理由这么做咯，我就随口瞎说的，别当真
毕竟那是你每天在上面工作的系统，又不是我的，你又不付钱给我做咨询
顺便说，看到你这么重视大型系统的架构，真的，那真的非常有必要呢

185 楼 gigix 2008-08-26  

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对象之间的序列化与反序列化完成的。

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

184 楼 starfeng 2008-08-26  

<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<p>说的比较上路，那么有以下几点可以讨论下</p>
<div class='quote_title'>starfeng 写道</div>
<div class='quote_div'><br/>四是说会有多个异构系统之间的信息交流。楼主也说了rails上对REST的支持，但相比SOA，它就好比碗中的一滴水（没用大海）。 </div>
<p> 我的疑问是，可以对这个SOA进一步解释下吗？为什么rest好比碗中的一滴水呢？</p>
<p> </p>
<p> </p>
<div class='quote_div'><br/><br/>那么。。。rails能做？或者不局限于某一框架，ruby能做？ <br/>我无法说将来，至少现在用ruby做的话，工作量太大，他缺少了企业级应用所需要的太多太多东西。 <br/></div>
<p>这个太多太多的东西包括？</p>
<p> </p>
<div class='quote_title'>写道</div>
<div class='quote_div'>总而言之，ruby能做的java基本能做，rails能达到的开发速度，java也能达到。rails没有明显优势。忽然我想，纯淬的抛java选ruby，其实只不过是抛弃现有的轮子再造一个带花的轮子而已————事实上，我更偏向于给现有的轮子加上花纹。</div>
<p> </p>
<p>那用.net开发企业级应用算不算重复造轮子呢？另外我的观点是用rails做大型应用适合，并不是java做就不适合，只是觉得重复造轮子一说值得商榷，莫非sun那么傻，费那么大劲发展 JRuby。</p>
<p> </p>
<p>就我而言，开发速度是rails明显比java快（个人观点）</p>
<p> </p>
<p>其实很多东西不好说，可以透漏一下，欧美很多外包企业级项目（不敢说是大型），选型rails，我要是没有一定这方面的信息，我也不会这么说，总体情况是方兴未艾吧。</p>
<p> </p>
<p>PS:当年学python时，问python社区的人python的发展情况，给我的的答案是：python给人的感觉很低调，原因是很多人用的很爽，不愿意告诉别人，比如google yahoo</p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p>1. REST<br/>SOA可以在网上搜得到大量文章，就REST这个通信部份，我就说一下：<br/>通常的项目中用不到，但当项目较大时，会遇到.Net和java的通信，老版本j2ee平台和新架构（比方spring，只是比方）的通信，这里老的项目支持某一种或两种协议，这时，你要调取别人的服务就得用别人能懂的协议，虽然，REST不错，但你这里无法对老的系统全改为REST，代价大，风险大。也许你会说，针对每种协议写一个Adapt就可以啊。是的，是一种方法。SOA（有很多轻量级open source的SOA，不一定非要用钱去买）对你说，你不用写了，我帮你写好了。<br/><br/>2. 太多太多的东西<br/>一是指各种component，像我们平时用的各种apache library，各种j2ee中提及到的服务（像tx, mail, jms等等）。rails在这一部份很缺少，虽然他的component在不断增长，但相比java，太少。<br/>二是指解决方案，方案这东西，不能保证你快，但他能保证你的安全，性能。上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应。rails在这一部份很缺少，你得在定方案前做各种检验。<br/>三是指兼容性与集成性，全新的东西是好办事，但你不能让企业把它运行得好好的东西全部重新开发吧。那么怎么集成，如何平滑的升级，这里又是一堆要做的东西。rails在这一部份也没怎么见过。<br/><br/>3. 轮子<br/>关从技术角度，.Net还真是这样。但从商业角度，从兼容性等方面来看，那就不是了。<br/><br/>4. 开发速度<br/>的确，j2ee的方式是慢，看上去java比不上rails，但是，这个问题要看架构师如何设计你的架构，如何利用或改装现有组件。思想是相通的，rails代表的是思想，而这种思想在java上实现是一样可以做到的。<br/><br/>5. 欧美项目<br/>我知道瑞士银行的一个核心项目也在用SSH（非门户之类，涉及到具体投资、资金方面），这句话好像有点抬杠，我主要是说，在面对新兴的技术，其实是有各种选择。rails最大的问题是优势不明显（从架构的角度），底气（component,项目证明等）又不足，所以现在不是它用于做大型应用的时候。</p>

183 楼 dualface 2008-08-26  

资源都 REST 了，客户端用什么都行。。。。。。搞不懂 ltin 的逻辑 @_@

182 楼 花花公子 2008-08-26  

企业应用≠大型应用
Flex做V很好，但是并不意味着他适合大型应用。网游还是大型应用呢，也没要求用rails做网游。
我就不明白，一个对脚本语言一窍不通，会一点flex的人，有什么资格评价rails。

引用

rail框架本身在V这里是短板。甚至不如JSF

RJS是非常好的东西，当然好东西不是所有人都知道。

181 楼 liuqiang 2008-08-26  

ltian 终于想通了，热烈欢送，也非常感谢不再过来淌浑水。
后续我会补上更多实例化的东西来讨论rails做金融系统的习得。
PS:大家让个台阶吧:)

180 楼 gigix 2008-08-26  

引用

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

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

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

179 楼 saturn 2008-08-26  

ltian 写道

hyf 写道

强啊！无敌啊！

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

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

这个我是觉得的赞成的..

对于,java和ruby而言,

java: 拿我同事的话说,java程序员至少在百年内不会灭绝的..

ruby: 如果以动态语言来说,百年外是不会灭绝的..

178 楼 murainwood 2008-08-26  

欧美大型企业应用,没见过Ruby的,倒见过PHP的....
不过PHP都能做,Rails应该也可以吧.

177 楼 liuqiang 2008-08-26  

<p>说的比较上路，那么有以下几点可以讨论下</p>
<div class='quote_title'>starfeng 写道</div>
<div class='quote_div'><br/>四是说会有多个异构系统之间的信息交流。楼主也说了rails上对REST的支持，但相比SOA，它就好比碗中的一滴水（没用大海）。 </div>
<p> 我的疑问是，可以对这个SOA进一步解释下吗？为什么rest好比碗中的一滴水呢？</p>
<p> </p>
<p> </p>
<div class='quote_div'><br/><br/>那么。。。rails能做？或者不局限于某一框架，ruby能做？ <br/>我无法说将来，至少现在用ruby做的话，工作量太大，他缺少了企业级应用所需要的太多太多东西。 <br/></div>
<p>这个太多太多的东西包括？</p>
<p> </p>
<div class='quote_title'>写道</div>
<div class='quote_div'>总而言之，ruby能做的java基本能做，rails能达到的开发速度，java也能达到。rails没有明显优势。忽然我想，纯淬的抛java选ruby，其实只不过是抛弃现有的轮子再造一个带花的轮子而已————事实上，我更偏向于给现有的轮子加上花纹。</div>
<p> </p>
<p>那用.net开发企业级应用算不算重复造轮子呢？另外我的观点是用rails做大型应用适合，并不是java做就不适合，只是觉得重复造轮子一说值得商榷，莫非sun那么傻，费那么大劲发展 JRuby。</p>
<p> </p>
<p>就我而言，开发速度是rails明显比java快（个人观点）</p>
<p> </p>
<p>其实很多东西不好说，可以透漏一下，欧美很多外包企业级项目（不敢说是大型），选型rails，我要是没有一定这方面的信息，我也不会这么说，总体情况是方兴未艾吧。</p>
<p> </p>
<p>PS:当年学python时，问python社区的人python的发展情况，给我的的答案是：python给人的感觉很低调，原因是很多人用的很爽，不愿意告诉别人，比如google yahoo</p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>

176 楼 starfeng 2008-08-26  

gigix 写道

引用

用Ruby能比用Java减少30%代码量这样结果不知道谁统计的？同样的功能？指哪些方面的功能呢？不要专门指Ruby擅长的或者Ruby自身封装的 API库里那部分功能？不知道Ruby做一个组态图形库的代码量如何？用Ruby写数学算法的代码会比java减少出30%吗？ 谢谢。

sigh
其实这个事情我都说过好多遍，说得都疲了…好吧再说一遍

companies.collect(&:departments).flatten.select{|dep|dep.location=="Shanghai"}.collect(&:employees).flatten.uniq.size

拿Java写一个来看看？
有些东西啊，既然别人这么言之凿凿的说，那肯定是有一定道理的，别人肯定是想过的
您这上来就“我们如何如何”，行，您什么都知道了，我也没啥必要非得说服谁不可，我又不损失什么

现在的java还没有引入闭包，所以不能完全一样，但也不复杂：
假定，我有这么一个Util class: Setting
它有如下方法：collect, select, flatten, uniq, size
那么以如下方式构造companies后： Setting companies = new Setting(company1, company2 ...)
访你的ruby写法会是什么样子呢：

Closure closure = new Closure<Department>() {
    public Object exec(Department dep) {
       return dep.location = "shanghai";
    }
};
companies.collect(".departments").select(closure).collection(".employees").uniq().size()

差了很多没？除了闭包得用inner class的方式实现，带来了一些复杂度外，其它的都差不了多少。

rails使得ruby很火，让很多人以为ruby也会很火，正如当初java去抢c++的市场份额一样。事实上，除去rails，单说93年就出现的ruby，要是他真那么好，会到现在才火？我学ruby是02年或03年的时候，那时看过一篇讲aop的文章，从java讲到aspectJ，然后又讲到ruby，然后就试着学了一段时间的ruby，结果是：我不感冒。

至于rails的理念，我04年就在相关项目中用到了，那时rails还没出现。rails这种理念在面对简单业务(CRUD+Search)，会带来超爽快感，大大加快开发速度，但面对复杂业务时，又会回到原点，当然不是说会拖后腿。是很好的东西，但不是万能药，更不是ruby所独有的。

大型企业应用，有几个含义吧，
一是说要安全、性能好、并发（通常这点要求很少，反倒是各种门户网站在这方面要求高）
二是说大量业务：业务对象超多，几百到几千个。涉及业务对象多，为了某一个业务，要多达上十个业务对象的协作。
三是说开发的人员多，周期长（这个词可能不是很确切）：一个系统一个版本一个版本的升级，长达多年的生命周期，不同周期的软件架构升级与兼容。另外就是，开发人员都几乎能换几批。
四是说会有多个异构系统之间的信息交流。楼主也说了rails上对REST的支持，但相比SOA，它就好比碗中的一滴水（没用大海）。

那么。。。rails能做？或者不局限于某一框架，ruby能做？
我无法说将来，至少现在用ruby做的话，工作量太大，他缺少了企业级应用所需要的太多太多东西。

总而言之，ruby能做的java基本能做，rails能达到的开发速度，java也能达到。rails没有明显优势。忽然我想，纯淬的抛java选ruby，其实只不过是抛弃现有的轮子再造一个带花的轮子而已————事实上，我更偏向于给现有的轮子加上花纹。

175 楼 liuqiang 2008-08-26  

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>我们两个之间的争论不是在于RAIL能否则做企业开发，而是我不大赞同做大型企业开发时Rails能够以很大差别减少代码数量。你认为依靠Rails本身语言的简洁，我认为更大地依赖框架的运用。后来争吵也就是因为这样，很多Rails支持者们没有看清我说的，认为我否定Rails开发企业开发的可能性。所以口水战就开始了。我是一直做企业开发过过来的，应该算个老程序员了。对我来说，C/S系统升级到B/S系统中头一个难题摆在我面前的就是UI，也就是View的问题。我对乐观估计形式的兄弟们提出UI的三个需求，所有非议因此而来。 <br/><br/>不过现在我发现用RIA+Java可以有效解决UI的问题。我们的系统已经在试运行，用户反响不错。希望有机会和大家分享这方面的经验。即便想用Rail做服务器端，我认为企业开发的前端选型还是要慎重。既然大家觉得Rails那么简洁，我也会抽出时间学的。 <br/></div>
</div>
<p> </p>
<p> </p>
<p>1 你对rails又不熟悉，你干嘛非要过来插一脚，我真不明白。</p>
<p>2 rails就不能RIA了？你可以去了解下webORB和rubyAMF是干嘛用的，如果你认为只有java可以RIA，那么我就认为你的水平远远在刚入行者之下。</p>
<p>3 感觉你有点自大，吃了顿 flex这个鸽子蛋就认为天下无敌了，总是认为自己是正确的。</p>
<p>4 LS两位兄弟没错啊，人家说框架，ltian非说V，有人（没指ltian）干嘛非要给别人投个差票？另外发现前面也有几个无辜的帖子，不爽可以站出来说话嘛，这样不明不白瞎投算什么！</p>
<p>5 我不认为你对UI的理解有多深，一个合格的UI设计师起码能分的清javascript和java</p>