从架构思想上看:
JavaEE的(起码早期的)思想一直是 用大型架构 建设 错综复杂的商业系统(注意这些系统中web只是所用的众多技术中的一部分),导致他十分强调分层,开发部署比较繁重。
这个思想根深蒂固,几乎影响了所有java框架的设计。甚至所谓的轻量级框架也是如此。
(似乎成了企业级技术的特点,看看现在火热的SOA,其复杂和繁重程度甚至比JavaEE更严重)。
http://pig345.javaeye.com/blog/199384
ROR显然没这么大的野心,它要解决的只是如何快速搭建好一个网站(因此会更注重如何多多利用web标准:html、css、javascript),他在架构上的考虑就只是MVC,能保持一个好的程序结构即可,根本无须分层。
(与JavaEE这么多年一直拥抱SOA对比,ROR到了2.0更是抛弃了webservice,转到更加简洁的REST了)
但是sun没想到实际中大多数人开发的东西没那么复杂,反倒更强调快速开发、快速适应变化,因此ROR在java社区里面引起很大反思。
(在中国这个情况更加普遍,系统不复杂、倒是需求变化快。。。)
(在网站制作领域一直都是喜欢用脚本语言,可以做到快速编码、快速部署、快速变化。PHP就是一个例子,只不过PHP结构实在太差,java们一直看不上眼,而ROR实现的MVC却相当正统、严密,框架结构甚至比流行的java框架如ssh作的更完美,这自然引起了java们的广泛兴趣)
然而实际作起来,你会发现:
1)从语言环境到应用框架都不熟悉,需要不短的一段时间学习和准备
(对于那些看了几天 文档/视频/教程 就敢轮胳膊开干,还说入门简单学习曲线低的,我真要骂人了:不是人您就别在人堆里面瞎炫耀了)
2)动态语言真的很动态,没有编译过程,你可能会犯下一些低级错误,而具体到Rails框架中,因为使用了各种动态的代码生成技术,导致要想搞清楚其中一些bug,可能需要你花费几个小时进行跟踪查找。
3)Rails中的View是基于html的模板技术,这跟jsp类似,你需要自己控制自己,因为没人会阻止你在里面写业务代码。
4)ruby之前应用的还比较少,一些常见解决方案还非常不完善(比如:全文检索,目前最好的ferret,还是有bug经常导致rails意外退出)。
5)Rails的各种插件比较多,但是质量不齐,有些看起来很cool,但是无法深入定制(比如:ROR书里面提到的streamlined,就有点像玩具),具体的调研和选择代价比较大。
6)有时碰到Rails插件的bug或功能缺陷,如果你自己直接改的话,之后的插件升级版本管理上似乎会有点麻烦,需要你手工合并。
7)可能你要自己解决部署后的源代码保护问题,而这个问题对于产品开发无疑是最重要的。
8)动态语言的全面掌握需要比静态语言花费更多时间精力。
呵呵,泼了这么多凉水,其实是想说明一点:要认真地对待ROR技术,不要被一些宣传所蒙蔽。
基本上,在没有熟练掌握ROR、而又需要深入开发的时候,ROR带来的好处(代码量少、开发修改部署快),和他带来的各种问题几乎可以互相抵消,千万别以为能省多少时间。
但是从长远看,代码量少还是非常吸引人的,想象一下,同样的业务逻辑代码,10万行和100万行那个更容易维护?
偶然和一个作过ROR的开发人员有过一次交流,发现大家目前的想法有点相似,ROR更适合少量的高手合作开发,或者私人接活。
普通的团队开发似乎还需要大量探索。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12058779/viewspace-1005240/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12058779/viewspace-1005240/