ruby on rails为什么暂时无法成为企业应用开发的主流?
来源:百度文库 编辑:神马文学网 时间:2024/04/29 07:42:53
ruby on rails为什么暂时无法成为企业应用开发的主流?
http://www.javaeye.com/article/24499
今天上午和庄表伟在msn上交流了一些看法,下午和JavaEye2.0的主力开发人员jerry讨论了关于ruby on rails在企业应用开发和团队协作的问题。通过讨论,有了一些初步的想法和观点,虽然还不是很清晰,但是现在总结和记录下来,留待今后的实践来验证。
ozzzzzz在Java将死?中提出了一个衡量未来主流工业语言的标准,其中有一条很有意思:
ozzzzzz 写道
1. 应该能规范书写,而不是像c那样可以造就多种不同的风格。
Java明显是一个编程风格非常容易统一起来的语言,而ruby则很明显是一个难以统一编程风格的语言。JavaEye论坛里面有人曾经说过:
引用
Java语言,高手和低手写出来的代码都差不多,而ruby则不同,高手和低手的代码,高下立判
Java编程语言的语法非常简单,规范比较严密,这样规范化带来的好处就是,一旦程序员具有比较良好的面向对象编程基础和设计模式的掌握,那么编写出来的代码几乎是大同小异的。
为什么优秀的Java开源框架的源代码我们读起来都比较容易呢?为什么Java那么容易写出来无二义性,相似度那么高的代码风格呢?为什么用Java做同样一件事情,往往只有一种最优的写法呢?为什么Java很难搞出来奇技淫巧呢?为什么Java语言一直被人认为是大巧若拙呢?我们再想想,为什么JDK5.0引入的技巧颇高的泛型编程到现在也有三年,为什么还是没有被广泛采用?再想想Java语言被设计出来是用在什么场合的呢?
想清楚这些问题,那么我们就会发现Java成为企业应用开发主流的一个内在原因(外因也很多,这里不谈),因为Java语言足够死板!
所以写Java程序没有什么花巧,所以为了弄出来点花巧,逼的Java社区搞出来动态反射,搞出来AOP,抄袭了泛型,其目的都是增加Java语言的灵活性。
那么Java这种死板而简单的语言有什么好处呢?好处就是适合作为工业语言!
那么我们分析一下工业语言在语法上面有着什么样的要求呢?
1、语法足够简单而且强壮
2、语法足够死板、做同样的事情,只有一种最优解
3、足够的语法障碍,抑制你的随意发挥,给我规规矩矩的编码
工业语言为什么有这种内在的要求呢?
1、团队协作的需要
大规模的项目需要几十人以上的协作,甚至是异地协作。这种大规模的团队协作要求程序员的代码风格必须高度一致,并且代码块之间的依赖性降到最低。显然死板而容易解藕的Java非常的合格
2、批量生产的需要
现在的软件外包产业体现的尤为明显!不需要你的创意,不需要你的设计,就需要你的coding,而且coding风格,功能已经规定死了。Java显然又非常合适。
好了,上面分析了从语法特点角度,为什么Java成为了工业语言,那么再分析一下为什么ruby不能成为工业语言:
1、ruby的语法过于灵活,发挥的余地太大,导致每个人的代码风格迥异
我刚开始学习ruby的时候非常不适应,被ruby五花八门的语法糖衣搞晕了,同样的一件事情,你有无数种做法,笨拙的,普通的,聪明的,天才的,各式各样,甚至有本《ruby quiz》的书专门讲解ruby编程的各种奇技淫巧。ruby这种内在语法特性直接造就了ruby on rails奇迹。在ruby on rails框架里面,有无数的ruby magic,好用之极又让你惊喜万分,没有ruby这么多灵活的语法支持,rails变不出来这么多魔术。
但是ruby的语法灵活性恰恰是成为工业语言的一大障碍!Java绝顶高手和Java普通高手的代码在风格上不会有大的差别(我就不觉得Rod Johnson代码比我高明到哪里去),但是ruby绝顶高手和ruby普通高手的代码简直判若云泥!高下立判!绝顶高手如DHH把ruby用的出神入化叹服之余,也让你我之辈根本无法写出来符合DHH风格的ruby代码。
在我们JavaEye2.0网站开发中,也出现了这种问题,两个人写的ruby代码,互相之间理解起来存在困难。而由于做一件事情有很多ruby写法,不同性格的人甚至都会选择不同的实现方法,在一个团队中,要统一编码风格,实在难乎其难!而在Java项目中,基本可以杜绝此类问题。
由于代码风格难以统一,因此在大规模的团队中使用ruby编程,会造成合作上面的障碍!
2、ruby on rails会导致你的代码藕合度非常高,不利于团队协作开发
由于rails规定死你的代码框架,不论是横向的功能解藕,还是纵向的分层解藕,都比较困难。
首先来说纵向的分层解藕,这是Java大规模项目常用的办法,但是在ruby on rails中基本不可能。因为ruby on rails各层之间的隐式约定太多了,你不可能分层开发。目前ruby on rails项目都是建议横向功能解藕,不建议纵向分层解藕的。
再说横向功能解藕:首先每个人必须承担足够大颗粒度的功能模块,不能拆分的太细了。因为rails的一个Controller文件就代表一大块功能了。
例如JavaEye2.0中,整个forum就只有一个controller,整个blog也就只有一个controller。当然你惊叹,整个forum代码就一个文件搞定了啊,代码太少了!但是反过来,你也可以说,论坛这个功能只能交给一个人来做了,没有办法再拆分功能了。这就带来了一个问题,团队协作变的困难了,如果两个人同时做论坛模块,就会出现经常性的该controller文件冲突合并。即使妥协一下,每个人只负责一个大功能块,但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。
但是Java不存在这个问题,为什么呢?因为Java把一个Controller分解成为了无数个小Action,把一个Model分解成为了PO,DAO,Service,进行了充分的功能职责的解藕,每个人的工作基本不会互相干扰,那么团队协作的问题就好办了。
在JavaEye2.0开发过程中,就遇到了这个问题,即使是分出来一小部分任务,也经常性导致文件冲突合并,最后只能把大部分的程序任务压到了jerry一个人身上。可敬的jerry同学几乎以一人之力编写了整个JavaEye2.0的绝大多数代码。在惊叹jerry以一个人月的高效率完成整个JavaEye2.0编码工作的同时,我们也不得不反思,为什么ruby on rails这样难以团队协作开发呢?
在我最推崇的《Getting Real》这本书里面建议一个开发团队3个人足够了,一个人设计规划产品功能,一个人设计界面,一个人编写代码。我们现在也是这样的:robbin设计产品功能,ouspec负责界面,jerry编写代码,然后robbin和ouspec负责测试。但并不是所有的项目都可以靠3个人搞定的,大规模应用项目团队协作进行开发,我们目前还没有答案。
jerry有个观点我非常赞同,他认为目前我们没有找到合适的团队协作方法是因为现在的软件开发方法都不适合ruby on rails开发团队。而真正适合ruby on rails的软件开发方法究竟是什么样子,现在还没有出现,恐怕需要人们的探索了。ruby on rails流行必须伴随着适合ruby on rails的软件开发方法一起出现才行。
因此在人们总结出来这种适合ruby on rails的软件开发方法之前,ruby on rails仍然会被局限在web2.0开发领域,在这个领域,ruby on rails的所有优点将发挥的淋漓尽致,而缺点将会被回避开。不过一旦涉及到企业应用开发领域,我们将面临这些问题。
因此,我的结论就是ruby on rails目前尚且不适合企业应用项目的开发。当然如果有适合ruby on rails的软件开发指导方法的出现,或者企业应用本身的定义已经发生了彻底的改变,那么我的结论也就不复存在了。
用一句话来总结就是:
ruby on rails是武林高手的绝世宝剑,却不是两军对垒中士兵使用的常规作战武器(Java却是这种常规武器)。
BTW:我抛出来这个结论,并不代表我的想法已经很成熟了,事实上这也只是我们第一次尝试使用ruby on rails,在不熟悉不了解的情况下做出结论,未免过于草率,但是我之目的在于抛砖引玉,目前我们在开发中遇到了这些团队协作方面的问题,希望我的抛砖能够引出来好玉,解决这些我们还没有想到很好解决办法的问题,多谢啦,哈哈!
评论 共 40 条发表评论
江南白衣 2006-09-17 00:43
同意Java下大家的代码都差不多。
但如果大家都只是老老实实的用rails的api写基本应用代码时,是不是也能差不多?
firebody 2006-09-17 01:14
标题打得好高啊。
rails 现在的主要目标是成为 web开发的主流 就已经很不错了。
等这个目标拿下了,再考虑成为企业应用的主流吧。
另,从你的描述的情况来看,似乎你的设计违背了一些OO的基本原则(比如职责过多..)
这些OO的原则和具体的OO语言无关,既然Rails是一个OO的框架,我想这些原则的遵循还是可以被遵循的。
对rails没有使用经验,仅仅从OO的角度来看待问题。
其实,从我的个人经验来看,如果平时不注重代码重构的,在更灵活的环境里面,更加容易犯这个错误。
从java 到 rails,灵活程度上升了一个台阶,原来在用java开发的时候所存在的问题 在 rails或许加了一个放大倍数也不一定呢? 赫赫
robbin 2006-09-17 03:10
rails框架已经约定要求你这样做了,这个没有什么变通的余地,除非你愿意很别扭的使用rails,或者放弃rails。
rails的ActiveRecord模型也本来就不是符合OO原则的,这已经是尽人皆知的事情了。
buaawhl 2006-09-17 06:34
robbin 写道
例如JavaEye2.0中,整个forum就只有一个controller,整个blog也就只有一个 controller。当然你惊叹,整个forum代码就一个文件搞定了啊,代码太少了!但是反过来,你也可以说,论坛这个功能只能交给一个人来做了,没有办法再拆分功能了。这就带来了一个问题,团队协作变的困难了,如果两个人同时做论坛模块,就会出现经常性的该controller文件冲突合并。即使妥协一下,每个人只负责一个大功能块,但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。
一个URL,对应一个Action (Controller),Java MVC里面也是这样的。Spring MVC就是很多Controller。
只是Rails的URL分为两级,forum/index, forum/show。大家喜欢把index, show变成method而已。
完全可以像topic那样拆分出来,forumIndex, forumShow。
关于model, Rails没有限定一个controller只能使用一个model吧?
只看过RoR book的相关部分,强烈期待各路Rails好手的意见。
--------------------------
Rails的设计,相当于大量使用 code generation,这只是ruby语法的少数特性而已(mixin, etc),还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎,猴子称霸王的状态。等到Ruby足够红火,引得一批Java MVC高手过来,这个局面立刻改观。
我做MVC不怎么样,看到RoR都觉得技痒,感觉用Ruby可以很容易做出不错的MVC,想怎么整,就怎么整。只是还是对Ruby性能有些过虑,对自己能力信心也不足,不敢这么快跳进来,精力暂时放在别处。
一旦这个语法潜力爆发出来,Ruby的各个领域,都会百花齐放,欣欣向荣。在Java里面辛辛苦苦整出来的各种特性(AOP,Dynamic Deployment,Runtime Monitor,Law of Demeter... etc),在Ruby里面轻而易举。
Ruby这类动态语言,非常适合做容器和动态组件,而这是企业应用的一个关键特性之一。未来的Web Service Client更是动态语言的天下。
Ruby的问题在于基础设施太薄弱,而且意志很薄弱,还很自满,号称只做必要的,不做重复的。宁可嵌入C, 宁可包装半天引用C Lib,也不愿意直接向这些领域进军。后劲儿严重缺乏,最终,可能只是进行了动态语言的普及教育,给其他语言作了嫁衣。
搞到后来,可不就是只做必要的,就做Web/MVC/ORM这块最有前途、最简单重复的领域吧。就在Web2.0这个小潭子里面可劲儿折腾吧。
不过我相信,有识之士已经在偷摸鼓捣了。搜索了一下Sourceforge,Ruby Project 400多个,Corba, Map Reduce之类的,也都有了,还是一个可喜的进步。
(Python 3000多个。可能是Ruby宣传工具很厉害,大家有个感觉,Python败给Ruby了。殊不知,Python的用户量正在直追Perl,而Ruby短期内翻了14倍,也才是Python的1/3。当然,如果Ruby的增幅可以这么持续下去,很快连头牌Java都可以超过)
--------------------------
Ruby的Code Style Check应该比Java容易做,至少不用antlr, javaCC等Parser Generator了,动态语言自个儿就偷摸搞定了。
搜索了一下,只发现了一个工具。市场还不繁荣。
http://www.cs.umd.edu/~nspring/software/style-check-readme.html
不过,可以想见,一旦这方面的需求有了,各种code style checker会雨后春笋般冒出来。
levinfox 2006-09-17 11:06
buaawhl 写道
一个URL,对应一个Action (Controller),Java MVC里面也是这样的。Spring MVC就是很多Controller。
只是Rails的URL分为两级,forum/index, forum/show。大家喜欢把index, show变成method而已。
完全可以像topic那样拆分出来,forumIndex, forumShow。
关于model, Rails没有限定一个controller只能使用一个model吧?
只看过RoR book的相关部分,强烈期待各路Rails好手的意见。
这样就向java退化了一步,rails带来的收益也立马减少了很多。
引用
Rails的设计,相当于大量使用 code generation,这只是ruby语法的少数特性而已(mixin, etc),还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎,猴子称霸王的状态。等到Ruby足够红火,引得一批Java MVC高手过来,这个局面立刻改观。
据我观察,从java迁移到ruby的主力是以前有很深smalltalk背景的以及咨询/图书业者,真正直接从java开源社区过去的干将,太少了,好像除了testng的Cedric还真没看到别的(即便是他,也仍然还抱着java)。
这两个社区的文化差异太大,尤其是rails社区,如果不改一改风格,要想进一步吸引开发者而不是使用者,是很难的.
不过,从perl转向ruby的倒是有不少,但是多数还在等待perl6
引用
Python 3000多个。可能是Ruby宣传工具很厉害,大家有个感觉,Python败给Ruby了。殊不知,Python的用户量正在直追Perl,而Ruby短期内翻了14倍,也才是Python的1/3。当然,如果Ruby的增幅可以这么持续下去,很快连头牌Java都可以超过
从开源项目开发者的平均水平来说,python的可能还要略高于java,ruby现在缺乏资深人士的介入
引用
Ruby的Code Style Check应该比Java容易做,至少不用antlr, javaCC等Parser Generator了,动态语言自个儿就偷摸搞定了。
robbin的意思好像不是指style方面的,而是都符合style的情形下的多样性
ajoo 2006-09-17 13:13
稍微看了一下rails的tutorial(否则robbin的话都看不懂)
针对robbin的说法有几个问题:
1。为什么说active record不OO?具体指什么?
2。关于纵向分解。什么妨碍了纵向分解?view和controller就是可以分开的吧?如果存在active record不缺省支持的复杂的business logic,难道不可以单独独立出来么?ioc注射我是没有看见怎么解决,因为似乎model对象的创建都是framework自己封闭搞定的。但是service locator没问题呀。或者聪明些,弄一个统一的类似"dependency :service1, :service2, :service3"的这种东西来,和一个外部ioc容器连接起来都没有问题。
3。关于横向分解。ruby应该是有mixin的吧?那么,不同的人分管一个controller的不同action,写成module,最后mixin进来不成么?
buaawhl 2006-09-17 13:14
首先,感谢楼上的详细解答和丰富信息。
另外,看了《getting real》,一家伟大的公司──37signals,及他们的 Ruby on Rails。还找了一个读书笔记。
http://blog.donews.com/dengyu/archive/2006/03/20/777440.aspx
引用
1、少做点,做精些
更少的功能 -- 专注于解决简单的问题,将其他复杂、头痛、难解的留给对手
更少的选择和选响
更少的人和公司结构
更少的会议
更少的承诺
2、闭门造车
相似性 -大家都是类似的,所以你遇到的问题别人也会遇到
热情 -只有为你自己解决问题,你才能有热情真正的使用和关心它
3、花自己的钱
只有花自己的钱才能干“小事”,干”快事”
“限制”产生创意,再各种条件的限制下才能激发创意去解决问题
4、灵活的Scope
如果不能准时和按照预算完成项目,那就将减少scope. 总有时间增加其他的东西.
发布一个更少scope的产品总好过发布一个满是漏洞的要好。
保持scope灵活的方法
a. 定义优先级
b.实际的期望值
c.灵活性
5、找个敌人
驱动力因素
不同的定位或者“故事”
6、享受过程
保持产品可管理和控制性,并且享受其中的过程和乐趣!
我想起Potian给出的一个Link,叫做beating the average。是讲Lisp的。
我基本同意其中的观点 —— 语法决定论。一门语言最强大的就是语法了。
Ruby的语法不是成为企业应用的障碍,正相反,Ruby的语法是占领企业应用市场的法宝。
从前的script(js,perl,php)的问题在于模块化管理很差,这些是动态语言难以管理的主要障碍。
而对于ruby, python来说,模块化已经做的非常好,package, module, class,完全具备了大规模代码管理的潜力。
当然,缺乏编译期类型检查可能是一个问题。但是,可以采用TDD,Code Analzyer等辅助手段来缓解。
Ruby的阻碍在于什么呢?
我的个人看法,成也萧何,败也萧何。成也Rails,败也Rails。
“专注于解决简单的问题,将其他复杂、头痛、难解的留给对手”
看看这个口号。谁也不是傻瓜。谁不知道做简单赚大钱的事情。
Signal37成功了,但是这种模式是无法简单复制的。大家都争着去做简单的事情得了。
确实,人类还有相当多的随便实现一下就可以满足的简单需求可以挖掘,但是肯定远远少于Web2.0公司的数目。
关于Ruby, Python的潜力。
http://buaawhl.javaeye.com/blog/21333
引用
下一代(大众)语言霸主应该具备的条件
关键字: 企业应用
这是BJUG里面讨论Java前途,Ruby前景的时候,我写的一篇回复。贴在这里。
下一代(大众)语言霸主应该具备的条件
语法的延续性?
静态类型安全?
-----
有一本书叫做 beyond java。
介绍了java的主要竞争对手。Ruby (Rail), Python, .net ( C Omega)
次要对手,php, lisp, smalltalk (seaside), perl, FP.
那篇Java不适合SOA的文章,主要讲了Java的跨平台的虚拟机在SOA方面没有优势,因为代码不需要移动。(我感觉很奇怪,B/S结构不也是这样)。然后下了一堆结论,不论从任何一个方面看,Java就是不适合SOA。可能是摘要。具体参数例子,没有看到。
最感兴趣的部分就没有看到。
liusong说的Web Service Client,我也有同感。
Web Service Client 绝对是Script的天下。编译语言丑陋的WSDL binding令人难以容忍。
我看了Java, C# 的generated stub,就下定了决心,除非有很多钱赚,不然拒绝采用编译语言作web service client。:D
Web B/S 方面(主要是server side开发),script实现Bean Utils, OGNL之类更容易,还有continuation,这是一点优势,但毕竟是server side,还有大量的数据处理部分,我认为,这些优势还不够保证Server Side的天下。且观望着。
--- 下面回顾一下Java的历史和现状,看看下一代语言霸主应该符合怎样的条件
Java的开发效率从来就没有达到过最高。只是比C++高。而C++是上一代霸主。
Lisp, Smalltalk就一直号称比Java开发效率高。
首先来定义一下,什么样的语言,才能称为霸主。
1. 程序员数目最多。
Web内容管理方面的开源项目,PHP项目的数量和质量都远远超过Java。但是,却和人数不成正比。可见脚本语言的开发效率有多高。
为什么开发效率相对不高,Java为什么还能够保持这么大的程序员数目?
我猜想,可能和静态类型安全有关。也可能和语言的延续有关。
回顾一下语言简短的历史。C语言是 C++之前的语言霸主。
c, c++, java的语法基本一脉相承。
比如,= , ==, 这样的语法。我的个人观点,看上去就是不如 :=, =好看。但是保持了一种延续性。
2. 其他语言都把它作为比较标准。
几乎所有的语言都把Java作为开发效率和运行效率的比较标准。
比Java开发快多少。比Java运行快多少。从以前到现在,从来就没有间断过。
从这点看,Java确实是当之无愧的霸主。
Gosling :如果你看看它们的程序,你就会发现,它们看起来就像Java程序一样。
殊不知,这正是关键所在。
Ruby, Python, C# 之所以被称为Java的主要竞争对手。是因为他们保持了语言的延续性,就是说,它们看起来像Java。正如Java看起来像C++。
PHP也认识到了这种傍大款的好处,PHP5也开始看起来像Java。只是有些晚。并且对PHP从前的用户并不是很友好。有点 c 到 c++的意味。不过,我还是很看好PHP的,毕竟原有的程序员基数巨大。
----- 静态类型安全的魔咒
动态语言是否能够打破静态类型安全的魔咒, 成为语言霸主?
下一代语言霸主是否还是静态类型语言?
我们来看看,虽然是静态类型,c的类型其实不太安全,c++,Java的类型就比较安全,所以更加流行。以至于很多人依赖于静态类型安全。
复杂系统中,如果没有一个静态类型系统作为保障,很容易迷失方向。
静态类型安全是否必要?
TDD的经验,令很多人改变了看法,不再像以前一样依赖于静态类型安全。尤其是开发经验相当丰富的开发高手。
这里就有一个问题。
静态类型安全目前是适合大众的需求,所以,静态类型安全语言,才能成为大众语言。
高手的摆脱静态类型安全的开发经验(TDD等),能否普及到大众?
大众能否同样摆脱静态类型安全的依赖?这是一个很关键的问题。
如果大众摆脱不了对静态类型安全的依赖,那么动态语言就无法成为大众语言,无法成为语言霸主。(如果是这样,唯一的挑战Java霸主地位的只有C#了)。
我想,时代总是进步的。大众早晚都会摆脱对静态类型安全的依赖。只是早晚的问题。但这个早晚非常重要。比如, Non Static Type的 Smalltalk历史更加久远,更加OO,更加优雅,开发效率更高,但是一直没有成为主流,直到c++ like, static type safe的Java崛起之后抢尽了所有风头,从此smalltalk一蹶不振,错失良机,人数缩水。
这里的时间点问题,就在于,高手的摆脱静态类型依赖的开发经验,能否普及到大众,以便助动态类型语言登上大众语言的霸主宝座。
------ 静态类型确实影响重用
有时候,为了一些通用算法的重用,不得不统一interface,引入类型强制转换,放弃类型安全(我还是反对大量使用目前的Reflection API,因为那套API实在是麻烦)。
(Static Type FP 如 Haskell, OCaml是如何解决这个问题的,由于不熟悉语法,我还没有参透。好像他们的Type相当于Meta Class,Super Type,而Class相当于Data)
放弃了类型安全,还有些不甘心,于是引入运行时类型检查。
Class 之间利用 isAssignable 进行前后代的距离检查,instanceof 进行最后一关检查。以至于引入了一个复杂的Class检查体系。后来我发现,虽然没有使用reflection,但是做的这套工作和Script做的工作也差不多。JavaScript不也是采用 if (o.method) 来进行类型安全检查吗?而在编译里面做运行时类型检查比动态语言费劲多了。
这违反了我的原则 —— 用一门语言应该尽量发挥它的长处,而不是总想着避免它的短处。于是我放弃了这套工作。
静态类型负面效应,最臭名昭著的例子,就是完整的Visitor Pattern里面的 Visited Interface ( Visitable Interface )。里面的双重Type Dispatch。accept( visitor) { visitor.visit(this);}
这就是把静态类型用到极致的后果 (引起的类型循环依赖密集和广泛程度和难以想象,所有的不相关的visited type全都通过visitor interface相互网状交织依赖)
通常这种情况下,我宁可放弃类型安全。采用类型强制转换,也不愿意引入visited interface。
buaawhl 2006-09-17 13:31
ajoo 写道
稍微看了一下rails的tutorial(否则robbin的话都看不懂)
针对robbin的说法有几个问题:
1。为什么说active record不OO?具体指什么?
2。关于纵向分解。什么妨碍了纵向分解?view和controller就是可以分开的吧?如果存在active record不缺省支持的复杂的business logic,难道不可以单独独立出来么?ioc注射我是没有看见怎么解决,因为似乎model对象的创建都是framework自己封闭搞定的。但是service locator没问题呀。或者聪明些,弄一个统一的类似"dependency :service1, :service2, :service3"的这种东西来,和一个外部ioc容器连接起来都没有问题。
3。关于横向分解。ruby应该是有mixin的吧?那么,不同的人分管一个controller的不同action,写成module,最后mixin进来不成么?
active record 推荐继承,而继承override可能是其他语法没有、OO语法唯一独有的特色了。
从这点来看,active record 非常 OO。
说active record 不够OO,可能主要是说rails plugin给 active record 里面 mixin 更多的method。造成一个Object 的方法非常多,接口非常宽。
OO极端思想,一个类只做一件事情。从这个观点来看,确实不够OO。
mixin不是什么好东西。没办法的时候才用的。一般只应该用在框架中,正如cglib这些东西只能用在框架中,正经的项目开发中怎么能使用呢?
一般的小网站项目中可能没有那么多的service,都是curd,query和functional代码。service locator的帮助有限。
这里面的问题主要在于Rails的神话。简单就是美。
我觉得,rails虽然确实比PHP, Perl美。但还是不够美。
带有一定的鼓励quick and dirty的因素。
http://www.javaeye.com/article/24499
今天上午和庄表伟在msn上交流了一些看法,下午和JavaEye2.0的主力开发人员jerry讨论了关于ruby on rails在企业应用开发和团队协作的问题。通过讨论,有了一些初步的想法和观点,虽然还不是很清晰,但是现在总结和记录下来,留待今后的实践来验证。
ozzzzzz在Java将死?中提出了一个衡量未来主流工业语言的标准,其中有一条很有意思:
ozzzzzz 写道
1. 应该能规范书写,而不是像c那样可以造就多种不同的风格。
Java明显是一个编程风格非常容易统一起来的语言,而ruby则很明显是一个难以统一编程风格的语言。JavaEye论坛里面有人曾经说过:
引用
Java语言,高手和低手写出来的代码都差不多,而ruby则不同,高手和低手的代码,高下立判
Java编程语言的语法非常简单,规范比较严密,这样规范化带来的好处就是,一旦程序员具有比较良好的面向对象编程基础和设计模式的掌握,那么编写出来的代码几乎是大同小异的。
为什么优秀的Java开源框架的源代码我们读起来都比较容易呢?为什么Java那么容易写出来无二义性,相似度那么高的代码风格呢?为什么用Java做同样一件事情,往往只有一种最优的写法呢?为什么Java很难搞出来奇技淫巧呢?为什么Java语言一直被人认为是大巧若拙呢?我们再想想,为什么JDK5.0引入的技巧颇高的泛型编程到现在也有三年,为什么还是没有被广泛采用?再想想Java语言被设计出来是用在什么场合的呢?
想清楚这些问题,那么我们就会发现Java成为企业应用开发主流的一个内在原因(外因也很多,这里不谈),因为Java语言足够死板!
所以写Java程序没有什么花巧,所以为了弄出来点花巧,逼的Java社区搞出来动态反射,搞出来AOP,抄袭了泛型,其目的都是增加Java语言的灵活性。
那么Java这种死板而简单的语言有什么好处呢?好处就是适合作为工业语言!
那么我们分析一下工业语言在语法上面有着什么样的要求呢?
1、语法足够简单而且强壮
2、语法足够死板、做同样的事情,只有一种最优解
3、足够的语法障碍,抑制你的随意发挥,给我规规矩矩的编码
工业语言为什么有这种内在的要求呢?
1、团队协作的需要
大规模的项目需要几十人以上的协作,甚至是异地协作。这种大规模的团队协作要求程序员的代码风格必须高度一致,并且代码块之间的依赖性降到最低。显然死板而容易解藕的Java非常的合格
2、批量生产的需要
现在的软件外包产业体现的尤为明显!不需要你的创意,不需要你的设计,就需要你的coding,而且coding风格,功能已经规定死了。Java显然又非常合适。
好了,上面分析了从语法特点角度,为什么Java成为了工业语言,那么再分析一下为什么ruby不能成为工业语言:
1、ruby的语法过于灵活,发挥的余地太大,导致每个人的代码风格迥异
我刚开始学习ruby的时候非常不适应,被ruby五花八门的语法糖衣搞晕了,同样的一件事情,你有无数种做法,笨拙的,普通的,聪明的,天才的,各式各样,甚至有本《ruby quiz》的书专门讲解ruby编程的各种奇技淫巧。ruby这种内在语法特性直接造就了ruby on rails奇迹。在ruby on rails框架里面,有无数的ruby magic,好用之极又让你惊喜万分,没有ruby这么多灵活的语法支持,rails变不出来这么多魔术。
但是ruby的语法灵活性恰恰是成为工业语言的一大障碍!Java绝顶高手和Java普通高手的代码在风格上不会有大的差别(我就不觉得Rod Johnson代码比我高明到哪里去),但是ruby绝顶高手和ruby普通高手的代码简直判若云泥!高下立判!绝顶高手如DHH把ruby用的出神入化叹服之余,也让你我之辈根本无法写出来符合DHH风格的ruby代码。
在我们JavaEye2.0网站开发中,也出现了这种问题,两个人写的ruby代码,互相之间理解起来存在困难。而由于做一件事情有很多ruby写法,不同性格的人甚至都会选择不同的实现方法,在一个团队中,要统一编码风格,实在难乎其难!而在Java项目中,基本可以杜绝此类问题。
由于代码风格难以统一,因此在大规模的团队中使用ruby编程,会造成合作上面的障碍!
2、ruby on rails会导致你的代码藕合度非常高,不利于团队协作开发
由于rails规定死你的代码框架,不论是横向的功能解藕,还是纵向的分层解藕,都比较困难。
首先来说纵向的分层解藕,这是Java大规模项目常用的办法,但是在ruby on rails中基本不可能。因为ruby on rails各层之间的隐式约定太多了,你不可能分层开发。目前ruby on rails项目都是建议横向功能解藕,不建议纵向分层解藕的。
再说横向功能解藕:首先每个人必须承担足够大颗粒度的功能模块,不能拆分的太细了。因为rails的一个Controller文件就代表一大块功能了。
例如JavaEye2.0中,整个forum就只有一个controller,整个blog也就只有一个controller。当然你惊叹,整个forum代码就一个文件搞定了啊,代码太少了!但是反过来,你也可以说,论坛这个功能只能交给一个人来做了,没有办法再拆分功能了。这就带来了一个问题,团队协作变的困难了,如果两个人同时做论坛模块,就会出现经常性的该controller文件冲突合并。即使妥协一下,每个人只负责一个大功能块,但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。
但是Java不存在这个问题,为什么呢?因为Java把一个Controller分解成为了无数个小Action,把一个Model分解成为了PO,DAO,Service,进行了充分的功能职责的解藕,每个人的工作基本不会互相干扰,那么团队协作的问题就好办了。
在JavaEye2.0开发过程中,就遇到了这个问题,即使是分出来一小部分任务,也经常性导致文件冲突合并,最后只能把大部分的程序任务压到了jerry一个人身上。可敬的jerry同学几乎以一人之力编写了整个JavaEye2.0的绝大多数代码。在惊叹jerry以一个人月的高效率完成整个JavaEye2.0编码工作的同时,我们也不得不反思,为什么ruby on rails这样难以团队协作开发呢?
在我最推崇的《Getting Real》这本书里面建议一个开发团队3个人足够了,一个人设计规划产品功能,一个人设计界面,一个人编写代码。我们现在也是这样的:robbin设计产品功能,ouspec负责界面,jerry编写代码,然后robbin和ouspec负责测试。但并不是所有的项目都可以靠3个人搞定的,大规模应用项目团队协作进行开发,我们目前还没有答案。
jerry有个观点我非常赞同,他认为目前我们没有找到合适的团队协作方法是因为现在的软件开发方法都不适合ruby on rails开发团队。而真正适合ruby on rails的软件开发方法究竟是什么样子,现在还没有出现,恐怕需要人们的探索了。ruby on rails流行必须伴随着适合ruby on rails的软件开发方法一起出现才行。
因此在人们总结出来这种适合ruby on rails的软件开发方法之前,ruby on rails仍然会被局限在web2.0开发领域,在这个领域,ruby on rails的所有优点将发挥的淋漓尽致,而缺点将会被回避开。不过一旦涉及到企业应用开发领域,我们将面临这些问题。
因此,我的结论就是ruby on rails目前尚且不适合企业应用项目的开发。当然如果有适合ruby on rails的软件开发指导方法的出现,或者企业应用本身的定义已经发生了彻底的改变,那么我的结论也就不复存在了。
用一句话来总结就是:
ruby on rails是武林高手的绝世宝剑,却不是两军对垒中士兵使用的常规作战武器(Java却是这种常规武器)。
BTW:我抛出来这个结论,并不代表我的想法已经很成熟了,事实上这也只是我们第一次尝试使用ruby on rails,在不熟悉不了解的情况下做出结论,未免过于草率,但是我之目的在于抛砖引玉,目前我们在开发中遇到了这些团队协作方面的问题,希望我的抛砖能够引出来好玉,解决这些我们还没有想到很好解决办法的问题,多谢啦,哈哈!
评论 共 40 条发表评论
江南白衣 2006-09-17 00:43
同意Java下大家的代码都差不多。
但如果大家都只是老老实实的用rails的api写基本应用代码时,是不是也能差不多?
firebody 2006-09-17 01:14
标题打得好高啊。
rails 现在的主要目标是成为 web开发的主流 就已经很不错了。
等这个目标拿下了,再考虑成为企业应用的主流吧。
另,从你的描述的情况来看,似乎你的设计违背了一些OO的基本原则(比如职责过多..)
这些OO的原则和具体的OO语言无关,既然Rails是一个OO的框架,我想这些原则的遵循还是可以被遵循的。
对rails没有使用经验,仅仅从OO的角度来看待问题。
其实,从我的个人经验来看,如果平时不注重代码重构的,在更灵活的环境里面,更加容易犯这个错误。
从java 到 rails,灵活程度上升了一个台阶,原来在用java开发的时候所存在的问题 在 rails或许加了一个放大倍数也不一定呢? 赫赫
robbin 2006-09-17 03:10
rails框架已经约定要求你这样做了,这个没有什么变通的余地,除非你愿意很别扭的使用rails,或者放弃rails。
rails的ActiveRecord模型也本来就不是符合OO原则的,这已经是尽人皆知的事情了。
buaawhl 2006-09-17 06:34
robbin 写道
例如JavaEye2.0中,整个forum就只有一个controller,整个blog也就只有一个 controller。当然你惊叹,整个forum代码就一个文件搞定了啊,代码太少了!但是反过来,你也可以说,论坛这个功能只能交给一个人来做了,没有办法再拆分功能了。这就带来了一个问题,团队协作变的困难了,如果两个人同时做论坛模块,就会出现经常性的该controller文件冲突合并。即使妥协一下,每个人只负责一个大功能块,但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。
一个URL,对应一个Action (Controller),Java MVC里面也是这样的。Spring MVC就是很多Controller。
只是Rails的URL分为两级,forum/index, forum/show。大家喜欢把index, show变成method而已。
完全可以像topic那样拆分出来,forumIndex, forumShow。
关于model, Rails没有限定一个controller只能使用一个model吧?
只看过RoR book的相关部分,强烈期待各路Rails好手的意见。
--------------------------
Rails的设计,相当于大量使用 code generation,这只是ruby语法的少数特性而已(mixin, etc),还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎,猴子称霸王的状态。等到Ruby足够红火,引得一批Java MVC高手过来,这个局面立刻改观。
我做MVC不怎么样,看到RoR都觉得技痒,感觉用Ruby可以很容易做出不错的MVC,想怎么整,就怎么整。只是还是对Ruby性能有些过虑,对自己能力信心也不足,不敢这么快跳进来,精力暂时放在别处。
一旦这个语法潜力爆发出来,Ruby的各个领域,都会百花齐放,欣欣向荣。在Java里面辛辛苦苦整出来的各种特性(AOP,Dynamic Deployment,Runtime Monitor,Law of Demeter... etc),在Ruby里面轻而易举。
Ruby这类动态语言,非常适合做容器和动态组件,而这是企业应用的一个关键特性之一。未来的Web Service Client更是动态语言的天下。
Ruby的问题在于基础设施太薄弱,而且意志很薄弱,还很自满,号称只做必要的,不做重复的。宁可嵌入C, 宁可包装半天引用C Lib,也不愿意直接向这些领域进军。后劲儿严重缺乏,最终,可能只是进行了动态语言的普及教育,给其他语言作了嫁衣。
搞到后来,可不就是只做必要的,就做Web/MVC/ORM这块最有前途、最简单重复的领域吧。就在Web2.0这个小潭子里面可劲儿折腾吧。
不过我相信,有识之士已经在偷摸鼓捣了。搜索了一下Sourceforge,Ruby Project 400多个,Corba, Map Reduce之类的,也都有了,还是一个可喜的进步。
(Python 3000多个。可能是Ruby宣传工具很厉害,大家有个感觉,Python败给Ruby了。殊不知,Python的用户量正在直追Perl,而Ruby短期内翻了14倍,也才是Python的1/3。当然,如果Ruby的增幅可以这么持续下去,很快连头牌Java都可以超过)
--------------------------
Ruby的Code Style Check应该比Java容易做,至少不用antlr, javaCC等Parser Generator了,动态语言自个儿就偷摸搞定了。
搜索了一下,只发现了一个工具。市场还不繁荣。
http://www.cs.umd.edu/~nspring/software/style-check-readme.html
不过,可以想见,一旦这方面的需求有了,各种code style checker会雨后春笋般冒出来。
levinfox 2006-09-17 11:06
buaawhl 写道
一个URL,对应一个Action (Controller),Java MVC里面也是这样的。Spring MVC就是很多Controller。
只是Rails的URL分为两级,forum/index, forum/show。大家喜欢把index, show变成method而已。
完全可以像topic那样拆分出来,forumIndex, forumShow。
关于model, Rails没有限定一个controller只能使用一个model吧?
只看过RoR book的相关部分,强烈期待各路Rails好手的意见。
这样就向java退化了一步,rails带来的收益也立马减少了很多。
引用
Rails的设计,相当于大量使用 code generation,这只是ruby语法的少数特性而已(mixin, etc),还有很大可以提高的余地。只不过Ruby MVC 领域目前还处于一种山中无老虎,猴子称霸王的状态。等到Ruby足够红火,引得一批Java MVC高手过来,这个局面立刻改观。
据我观察,从java迁移到ruby的主力是以前有很深smalltalk背景的以及咨询/图书业者,真正直接从java开源社区过去的干将,太少了,好像除了testng的Cedric还真没看到别的(即便是他,也仍然还抱着java)。
这两个社区的文化差异太大,尤其是rails社区,如果不改一改风格,要想进一步吸引开发者而不是使用者,是很难的.
不过,从perl转向ruby的倒是有不少,但是多数还在等待perl6
引用
Python 3000多个。可能是Ruby宣传工具很厉害,大家有个感觉,Python败给Ruby了。殊不知,Python的用户量正在直追Perl,而Ruby短期内翻了14倍,也才是Python的1/3。当然,如果Ruby的增幅可以这么持续下去,很快连头牌Java都可以超过
从开源项目开发者的平均水平来说,python的可能还要略高于java,ruby现在缺乏资深人士的介入
引用
Ruby的Code Style Check应该比Java容易做,至少不用antlr, javaCC等Parser Generator了,动态语言自个儿就偷摸搞定了。
robbin的意思好像不是指style方面的,而是都符合style的情形下的多样性
ajoo 2006-09-17 13:13
稍微看了一下rails的tutorial(否则robbin的话都看不懂)
针对robbin的说法有几个问题:
1。为什么说active record不OO?具体指什么?
2。关于纵向分解。什么妨碍了纵向分解?view和controller就是可以分开的吧?如果存在active record不缺省支持的复杂的business logic,难道不可以单独独立出来么?ioc注射我是没有看见怎么解决,因为似乎model对象的创建都是framework自己封闭搞定的。但是service locator没问题呀。或者聪明些,弄一个统一的类似"dependency :service1, :service2, :service3"的这种东西来,和一个外部ioc容器连接起来都没有问题。
3。关于横向分解。ruby应该是有mixin的吧?那么,不同的人分管一个controller的不同action,写成module,最后mixin进来不成么?
buaawhl 2006-09-17 13:14
首先,感谢楼上的详细解答和丰富信息。
另外,看了《getting real》,一家伟大的公司──37signals,及他们的 Ruby on Rails。还找了一个读书笔记。
http://blog.donews.com/dengyu/archive/2006/03/20/777440.aspx
引用
1、少做点,做精些
更少的功能 -- 专注于解决简单的问题,将其他复杂、头痛、难解的留给对手
更少的选择和选响
更少的人和公司结构
更少的会议
更少的承诺
2、闭门造车
相似性 -大家都是类似的,所以你遇到的问题别人也会遇到
热情 -只有为你自己解决问题,你才能有热情真正的使用和关心它
3、花自己的钱
只有花自己的钱才能干“小事”,干”快事”
“限制”产生创意,再各种条件的限制下才能激发创意去解决问题
4、灵活的Scope
如果不能准时和按照预算完成项目,那就将减少scope. 总有时间增加其他的东西.
发布一个更少scope的产品总好过发布一个满是漏洞的要好。
保持scope灵活的方法
a. 定义优先级
b.实际的期望值
c.灵活性
5、找个敌人
驱动力因素
不同的定位或者“故事”
6、享受过程
保持产品可管理和控制性,并且享受其中的过程和乐趣!
我想起Potian给出的一个Link,叫做beating the average。是讲Lisp的。
我基本同意其中的观点 —— 语法决定论。一门语言最强大的就是语法了。
Ruby的语法不是成为企业应用的障碍,正相反,Ruby的语法是占领企业应用市场的法宝。
从前的script(js,perl,php)的问题在于模块化管理很差,这些是动态语言难以管理的主要障碍。
而对于ruby, python来说,模块化已经做的非常好,package, module, class,完全具备了大规模代码管理的潜力。
当然,缺乏编译期类型检查可能是一个问题。但是,可以采用TDD,Code Analzyer等辅助手段来缓解。
Ruby的阻碍在于什么呢?
我的个人看法,成也萧何,败也萧何。成也Rails,败也Rails。
“专注于解决简单的问题,将其他复杂、头痛、难解的留给对手”
看看这个口号。谁也不是傻瓜。谁不知道做简单赚大钱的事情。
Signal37成功了,但是这种模式是无法简单复制的。大家都争着去做简单的事情得了。
确实,人类还有相当多的随便实现一下就可以满足的简单需求可以挖掘,但是肯定远远少于Web2.0公司的数目。
关于Ruby, Python的潜力。
http://buaawhl.javaeye.com/blog/21333
引用
下一代(大众)语言霸主应该具备的条件
关键字: 企业应用
这是BJUG里面讨论Java前途,Ruby前景的时候,我写的一篇回复。贴在这里。
下一代(大众)语言霸主应该具备的条件
语法的延续性?
静态类型安全?
-----
有一本书叫做 beyond java。
介绍了java的主要竞争对手。Ruby (Rail), Python, .net ( C Omega)
次要对手,php, lisp, smalltalk (seaside), perl, FP.
那篇Java不适合SOA的文章,主要讲了Java的跨平台的虚拟机在SOA方面没有优势,因为代码不需要移动。(我感觉很奇怪,B/S结构不也是这样)。然后下了一堆结论,不论从任何一个方面看,Java就是不适合SOA。可能是摘要。具体参数例子,没有看到。
最感兴趣的部分就没有看到。
liusong说的Web Service Client,我也有同感。
Web Service Client 绝对是Script的天下。编译语言丑陋的WSDL binding令人难以容忍。
我看了Java, C# 的generated stub,就下定了决心,除非有很多钱赚,不然拒绝采用编译语言作web service client。:D
Web B/S 方面(主要是server side开发),script实现Bean Utils, OGNL之类更容易,还有continuation,这是一点优势,但毕竟是server side,还有大量的数据处理部分,我认为,这些优势还不够保证Server Side的天下。且观望着。
--- 下面回顾一下Java的历史和现状,看看下一代语言霸主应该符合怎样的条件
Java的开发效率从来就没有达到过最高。只是比C++高。而C++是上一代霸主。
Lisp, Smalltalk就一直号称比Java开发效率高。
首先来定义一下,什么样的语言,才能称为霸主。
1. 程序员数目最多。
Web内容管理方面的开源项目,PHP项目的数量和质量都远远超过Java。但是,却和人数不成正比。可见脚本语言的开发效率有多高。
为什么开发效率相对不高,Java为什么还能够保持这么大的程序员数目?
我猜想,可能和静态类型安全有关。也可能和语言的延续有关。
回顾一下语言简短的历史。C语言是 C++之前的语言霸主。
c, c++, java的语法基本一脉相承。
比如,= , ==, 这样的语法。我的个人观点,看上去就是不如 :=, =好看。但是保持了一种延续性。
2. 其他语言都把它作为比较标准。
几乎所有的语言都把Java作为开发效率和运行效率的比较标准。
比Java开发快多少。比Java运行快多少。从以前到现在,从来就没有间断过。
从这点看,Java确实是当之无愧的霸主。
Gosling :如果你看看它们的程序,你就会发现,它们看起来就像Java程序一样。
殊不知,这正是关键所在。
Ruby, Python, C# 之所以被称为Java的主要竞争对手。是因为他们保持了语言的延续性,就是说,它们看起来像Java。正如Java看起来像C++。
PHP也认识到了这种傍大款的好处,PHP5也开始看起来像Java。只是有些晚。并且对PHP从前的用户并不是很友好。有点 c 到 c++的意味。不过,我还是很看好PHP的,毕竟原有的程序员基数巨大。
----- 静态类型安全的魔咒
动态语言是否能够打破静态类型安全的魔咒, 成为语言霸主?
下一代语言霸主是否还是静态类型语言?
我们来看看,虽然是静态类型,c的类型其实不太安全,c++,Java的类型就比较安全,所以更加流行。以至于很多人依赖于静态类型安全。
复杂系统中,如果没有一个静态类型系统作为保障,很容易迷失方向。
静态类型安全是否必要?
TDD的经验,令很多人改变了看法,不再像以前一样依赖于静态类型安全。尤其是开发经验相当丰富的开发高手。
这里就有一个问题。
静态类型安全目前是适合大众的需求,所以,静态类型安全语言,才能成为大众语言。
高手的摆脱静态类型安全的开发经验(TDD等),能否普及到大众?
大众能否同样摆脱静态类型安全的依赖?这是一个很关键的问题。
如果大众摆脱不了对静态类型安全的依赖,那么动态语言就无法成为大众语言,无法成为语言霸主。(如果是这样,唯一的挑战Java霸主地位的只有C#了)。
我想,时代总是进步的。大众早晚都会摆脱对静态类型安全的依赖。只是早晚的问题。但这个早晚非常重要。比如, Non Static Type的 Smalltalk历史更加久远,更加OO,更加优雅,开发效率更高,但是一直没有成为主流,直到c++ like, static type safe的Java崛起之后抢尽了所有风头,从此smalltalk一蹶不振,错失良机,人数缩水。
这里的时间点问题,就在于,高手的摆脱静态类型依赖的开发经验,能否普及到大众,以便助动态类型语言登上大众语言的霸主宝座。
------ 静态类型确实影响重用
有时候,为了一些通用算法的重用,不得不统一interface,引入类型强制转换,放弃类型安全(我还是反对大量使用目前的Reflection API,因为那套API实在是麻烦)。
(Static Type FP 如 Haskell, OCaml是如何解决这个问题的,由于不熟悉语法,我还没有参透。好像他们的Type相当于Meta Class,Super Type,而Class相当于Data)
放弃了类型安全,还有些不甘心,于是引入运行时类型检查。
Class 之间利用 isAssignable 进行前后代的距离检查,instanceof 进行最后一关检查。以至于引入了一个复杂的Class检查体系。后来我发现,虽然没有使用reflection,但是做的这套工作和Script做的工作也差不多。JavaScript不也是采用 if (o.method) 来进行类型安全检查吗?而在编译里面做运行时类型检查比动态语言费劲多了。
这违反了我的原则 —— 用一门语言应该尽量发挥它的长处,而不是总想着避免它的短处。于是我放弃了这套工作。
静态类型负面效应,最臭名昭著的例子,就是完整的Visitor Pattern里面的 Visited Interface ( Visitable Interface )。里面的双重Type Dispatch。accept( visitor) { visitor.visit(this);}
这就是把静态类型用到极致的后果 (引起的类型循环依赖密集和广泛程度和难以想象,所有的不相关的visited type全都通过visitor interface相互网状交织依赖)
通常这种情况下,我宁可放弃类型安全。采用类型强制转换,也不愿意引入visited interface。
buaawhl 2006-09-17 13:31
ajoo 写道
稍微看了一下rails的tutorial(否则robbin的话都看不懂)
针对robbin的说法有几个问题:
1。为什么说active record不OO?具体指什么?
2。关于纵向分解。什么妨碍了纵向分解?view和controller就是可以分开的吧?如果存在active record不缺省支持的复杂的business logic,难道不可以单独独立出来么?ioc注射我是没有看见怎么解决,因为似乎model对象的创建都是framework自己封闭搞定的。但是service locator没问题呀。或者聪明些,弄一个统一的类似"dependency :service1, :service2, :service3"的这种东西来,和一个外部ioc容器连接起来都没有问题。
3。关于横向分解。ruby应该是有mixin的吧?那么,不同的人分管一个controller的不同action,写成module,最后mixin进来不成么?
active record 推荐继承,而继承override可能是其他语法没有、OO语法唯一独有的特色了。
从这点来看,active record 非常 OO。
说active record 不够OO,可能主要是说rails plugin给 active record 里面 mixin 更多的method。造成一个Object 的方法非常多,接口非常宽。
OO极端思想,一个类只做一件事情。从这个观点来看,确实不够OO。
mixin不是什么好东西。没办法的时候才用的。一般只应该用在框架中,正如cglib这些东西只能用在框架中,正经的项目开发中怎么能使用呢?
一般的小网站项目中可能没有那么多的service,都是curd,query和functional代码。service locator的帮助有限。
这里面的问题主要在于Rails的神话。简单就是美。
我觉得,rails虽然确实比PHP, Perl美。但还是不够美。
带有一定的鼓励quick and dirty的因素。
ruby on rails为什么暂时无法成为企业应用开发的主流?
[Ruby on Rails]Vim 开发 ruby on rails 完全配置
Vim 开发 ruby on rails 完全配置...
Vim 开发 ruby on rails 完全配置...
Ruby on Rails有用的插件
什么是Ruby on Rails
Ruby on Rails
什么是Ruby on Rails
Ruby on Rails的下载及安装以及开发环境的搭建
利用Radrails开发Ruby on Rails程序入门指南
利用RadRails开发Ruby on Rails程序入门指南
Ruby on Rails 之 Oracle 应用:简易教程
Ruby on Rails 之 Oracle 应用:简易教程
一个.NET程序员为什么学习Ruby on Rails?(转 InfoQ)
Ruby on Rails Cheat Sheet - Ruby On Rails - ILoveJackDaniels.com
What Is Ruby on Rails
Ruby on Rails 学习资料
Ruby on Rails 学习资料
ruby on rails:web2.0世界新生的创造力
ruby on rails:web2.0世界新生的创造力
RoR历险记:一个Java程序员的Ruby on Rails体验
RUBY ON RAILS:WEB2.0世界新生的创造力
跨越边界: Ruby on Rails 的秘笈是什么?
使用 ActiveScaffold 增强 Ruby on Rails 的功能