|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-26
seemoon 写道 neodoxy 写道 说说ROR开发的弱点:
Ruby目前漏洞太多,还未成熟 滥用plugins,gems造成的安全性问题 应用服务器的稳定性问题 其他都可以归结为 设计问题,能力问题,信仰问题 Ruby目前漏洞太多,还未成熟？？ for example? 滥用plugins,gems造成的安全性问题?? 这是应用的问题，看你会不会用了。别忘了说gem的功劳，现在java的库管理那一个差阿，所以出了个maven，但是maven很可惜也比较复杂，在我看来 应用服务器的稳定性问题？？javaeye目前看来还比较稳定，否则可能就看不到你这个贴或者我这个回帖了，开个玩笑 其他都可以归结为 设计问题,能力问题,信仰问题？？这些最好不讨论了，因为很虚，不如用事实和代码说话 显然你不关心Ruby/Rails的发展,也没听懂我的意思... 另外gem的管理也很糟糕,命名冲突问题,gem库的list造成的github与rubyforge的冲突,gem库获取的安全问题 除了以上这些急需解决的问题,RoR做应用就没有大障碍了,而是人在使用时出现的问题 这样解释明白了吧 |
| 返回顶楼 | |
|
发表时间：2008-08-26
neodoxy 写道 seemoon 写道 neodoxy 写道 说说ROR开发的弱点:
Ruby目前漏洞太多,还未成熟 滥用plugins,gems造成的安全性问题 应用服务器的稳定性问题 其他都可以归结为 设计问题,能力问题,信仰问题 Ruby目前漏洞太多,还未成熟？？ for example? 滥用plugins,gems造成的安全性问题?? 这是应用的问题，看你会不会用了。别忘了说gem的功劳，现在java的库管理那一个差阿，所以出了个maven，但是maven很可惜也比较复杂，在我看来 应用服务器的稳定性问题？？javaeye目前看来还比较稳定，否则可能就看不到你这个贴或者我这个回帖了，开个玩笑 其他都可以归结为 设计问题,能力问题,信仰问题？？这些最好不讨论了，因为很虚，不如用事实和代码说话 显然你不关心Ruby/Rails的发展,也没听懂我的意思... 另外gem的管理也很糟糕,命名冲突问题,gem库的list造成的github与rubyforge的冲突,gem库获取的安全问题 除了以上这些急需解决的问题,RoR做应用就没有大障碍了,而是人在使用时出现的问题 这样解释明白了吧 这个是不久前才出现的，我的理解，是开源项目宿主服务提供者由一家独大变成两家鼎立引起的，是人文和管理问题，只在infoq上看了报导，不知道还有什么连带问题，尤其技术方面，能不能更详细些？ |
| 返回顶楼 | |
|
发表时间：2008-08-27
看看这个线索：
liuqiang 写道 之前读了不少文章，说rails不大适合做大型的互联网应用或者企业应用，但通过实
际的使用rails，越发的发现rails做大型应用是个不错的选择。 然后楼主liuqiang从可维护性、性能、可伸缩性和系统切分上进行了分析。 后来 gigix 写道 其实，代码越少越容易维护，这个对于大型应用更要紧
liuqiang 写道 之前听gigix说，单个方法的代码行平均5行，并给了例证
后来 ltian 写道 预祝各位rail 粉丝能用几千行代码写一个大型系统。
ltian 写道 一个方法只有5行用任何语言都能实现。我用汇编语言都能实现。
后来 liuqiang 写道 gigix说的5行代码，是指在真实的项目中平均5行代码一个方法
后来 ltian 写道 这样的数据没有任何意义。因为任何语言，你要是把函数粒度划分的比
较细，都可以达到类似的效果。 标红为话题1。 后来 abcx 写道 代码多少重要吗，重要的还是可读性
后来 gigix 写道 我从来就没见过谁会认为100万行的项目会比10万行的容易维护的，甭管是什么水平。
后来 ltian 写道 您能说明用rails 开发的系统用10万行，而别的语言，比如java就要用100万行吗？
大型系统靠的是通用框架和组件来缩短代码行数，提高系统的稳定性和易维护性，而不是靠 语言本身吧？ 注意：标红为向话题2转换的伏笔。 后来 gigix 写道 companies.collect(&:departments).flatten.select
{|dep|dep.location=="Shanghai"}.collect(&:employees).flatten.uniq.size
拿Java写一个来看看？ 后来 mycybyb 写道 用java把那几个函数封装一下就可以了。
rails不就是把这些功能内置了吗。 还是那句话，java是语言,rails是框架，不具有可比性。用java也可以做个rails出来。 gigix 写道 sigh
你写出来看看啊。就当你已经封装好了，拉出来遛一个咯。 而且麻烦你搞搞清楚，这行代码可跟Rails一点关系都没有呢。 ltian 写道 咱们讨论道理，不是谁要说说服谁的问题。我的观点是，大型系统开发
方面，通用框架和平台的作用远远超出语言本身的作用。比如...... 标红为向话题2漂移。 ltian 写道 通过这样的代码来减少代码行，却牺牲了程序的可读性，我认为不可取。
ltian 写道 java也可以啊
department.getChildDepartmentList().add(custom.getDepartment()==null?custom.getDepartment ():new Department()); 不是一样的长而且啰嗦吗？ 后来 gigix 写道 你真的看了我写那行代码到底是在干什么吗？
回帖要先看帖。 后来 ltian 写道 我知道你想说你那行代码威力惊人，能实现很强大功能。但是我认为如果搞那么复杂的
一行代码不如 将其打散封装成一个函数，给其一个非常易读的名字。然后给别人调用，不是更好吗？我 现在开发的应用表现层不用JAVA，用Flex，后台用JAVA，再通过自己开发的成熟的框架，也能高效地实现 大规模应用的开发。至于Rail能否进行大规模企业开发，重点应放在支持框架的开发上。 标红为话题3的伏笔。 后来 Quake Wang 写道 gigix 写道 其实，代码越少越容易维护，这个对于大型应用更要紧
+1 让我用JavaEye的代码来做个验证，这是今年7月份时候JavaEye网站的代码状态 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 3006 | 2556 | 49 | 407 | 8 | 4 | | Helpers | 537 | 492 | 0 | 47 | 0 | 8 | | Models | 2169 | 1805 | 54 | 262 | 4 | 4 | | Libraries | 932 | 753 | 8 | 80 | 10 | 7 | | Model specs | 1270 | 974 | 0 | 0 | 0 | 0 | | View specs | 0 | 0 | 0 | 0 | 0 | 0 | | Controller specs | 181 | 101 | 0 | 0 | 0 | 0 | | Helper specs | 111 | 91 | 0 | 0 | 0 | 0 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 8206 | 6772 | 111 | 796 | 7 | 6 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 5606 Test LOC: 1166 Code to Test Ratio: 1:0.2 总共代码是5606行 这5000多行代码实现了新闻，论坛，问答，Wiki，博客，圈子，全文检索，后台管理等全部功能。 而且这还是我们对于Rails边学边做的，并没有进行多少代码重够的结果，很多Rails 2.X的新特性也都没 有用在上面。 大家可以根据自己其他类似项目的经验来估计一下，我的估计是用目前流行的Java框架完成这些功能，代 码量要在20000~25000行。 注：我记着前几个月也进行过话题1的讨论，有趣的是，ltian当时就是讨论的中坚力量。 当时，gigix、robbin和我都贴出了相关系统的stats，所以才有前面LOC/M为5之说。 后来 ltian 写道 这里面的功能都以数据库记录增删该为主，简单界面工作量相对大，做简单WEB界面是
Railde强项。 如果我让你做企业应用界面恐怕你就累死了，再让你用Rail实现电力、通信、银行的业务逻辑，恐怕也没 那么容易了。 这个系统无法代表大型企业应用，只能代表论坛类网站的开发。 ltian 写道 我提三个需求，用Rails能轻松实现，就说明我确实无知，我刚才是胡说，我冒犯了Rails 这个神圣的框架和各位高人。 1. 你用Rails弹出一个有模窗口（做企业应用应该知道有模窗口），然后用鼠标拖动起来移动这个窗口。 从这样窗口上选择一些数据然后再到主窗口上进行显示。 2.一个grid，有20列，屏幕显示不下。要求左边3行固定，剩余列用户可以根据需要左右滚动已能够全部 显示。 3.一个窗口有两个控件，左边一棵树，右边一个gird，要求二者之间可以通过拖动来改变宽度，以适应数 据的显示。 这是企业开发里面对界面的最常见和普通的要求。 标红为正式漂移到话题3。 gigix 写道 哥哥，这纯粹是JavaScript好不好？JavaScript library应该对后台用什么server完全
无知好不好？ 后来 ltian 写道 你们那些兄弟宣传Rail开发WEB多强，作页面多么快捷方便的时候和Java也是没有关系啊
。这时候站出来说这是客户端的东西，呵呵。有点意思。 ltian 写道 那你们的Rail凭什么号称自己做web开发很easy？我真是服了各位。被最终告诉我，这些
需求很难，是JavaScript管的和Rail是没有关系。 后来 Quake Wang 写道 你前面谈的需求完全是界面的东西，和后台用什么框架是无关的。
liuqiang 写道 其实我也是一番好意，想从架构的角度谈谈下rails其实做大型应用并没有想象的那
么糟糕，谈谈思路，我也没有干吼：rails就是适合做大型应用！ 另外我也没有否认java适合做大型企业级应用，你做你的我做我的，世界多一个选择难道不好吗？ 后来 ltian 写道 咱们抛开大型企业应用，就说小规模的WEB应用吧，主要要解决的难点有两个方面：
1.WEB人机界面的问题。我说的那三个人机界面需求是很普遍的，除了RIA技术外，其他WEB技术表现层技 术解决起来都很难。 2.后台业务逻辑开发。这取决于开发人员经验和设计水平，不考虑用存储过程来实现，我 们说说用面向对象的语言来开发业务逻辑，那么做得好与坏，质量的高低，取决开发者的经验，面向对象 设计能力，和使用那种语言关系不大。 所以，我实在看不出ROR在WEB企业应用到底比较Java好在哪里。 除了在话题3上做做文章，又开始不应该成为话题的话题4（标红部分） robbin跳出来重提话题1和话题2 这是针对话题1 robbin 写道 有点搞笑呀，这行ruby代码的可读性是非常好的，不需要你懂ruby的API，只要你对这
几个英文单词的意思比较熟悉，而且对回调有那么点概念，你不觉得这行代码就像读英文句子那么通顺吗 ？ 这行代码就是说： 把一堆公司的部门统统展开，选择那些位于“上海”的部门，然后把这些部门的员工 放在一起，去掉重复人员，统计这些员工总共有多少个人。 不要告诉我连这个意思你都看不懂。 后来 ltian 写道 核心的东西无非是该框架封装了一个Select方法可以取道符合条件的集合而已。
火星叔叔马丁 写道 无非...又见无非
c++无非比c多一个对象而已 java无非把c++的指针和繁复的功能去掉而已 C#无非是java换了几个关键字而已 动态语言无非只是多了些闭包功能而已 楼下继续造句 这是针对话题2 robbin 写道 工作流方面ruby是有的，但是目前比较简单，可能没有达到jBPM的完善程度；
图形开发库方面ruby的RMagic并不比Java2D，3D差呀，甚至性能更好； 应用建模框架是什么概念？你举个Java的开源例子给我听听看？ 企业建模也不明白，麻烦你也举个开源的Java例子？ 权限资源管理框架麻烦去看看看ruby版好吗？孤陋寡闻本不是错； 消息框架也麻烦你去看看ruby版，ruby的消息框架现在实在太多了； 后来 ltian 写道 哦，不会Ruby就是孤陋寡闻，问问比尔盖茨同志知道不知道ruby 。我说的这些都是我们
自己针对企业应用开发的，和开源的有类似，也有些是自己抽象出来的。我举这些东西是说企业开发中， 这些才是加快大规模应用开发效率，提高产品质量的核心东西，和语言本身无关。我有说过一句Ruby没有 这系统的吗？有本事自己有用Ruby做一个全面工作流系统才叫厉害。 火星叔叔马丁 写道 有本事自己写个浏览器出来才叫厉害...
有本事自己写个操作系统出来才叫厉害... 有本事自己写个驱动程序出来才叫厉害... 有本事自己写个CPU指令集出来才叫厉害... robbin 写道 仔细看看你上面自己说过的话。你自己先用ruby没有这些企业应用可能需要的库来否定
ruby，然后我告诉你其实ruby也是有这些库的，只不过你不知道而已。然后你自己就开始扯盖茨也不知道 ruby（你敢确信盖茨不知道ruby？那IronRuby是怎么回事？），否认你没有说过ruby没有这些东西，最后 又扯我要有本事，就自己用ruby开发工作流。我就纳闷了，我有本事也罢，没本事也罢，和用不用ruby开 发工作流有什么逻辑关系吗？ ltian 写道 不知道Ruby方面的东西就是孤陋寡闻，太不讲理了吧。而且我从来没有说过Ruby不能开
发工作流之类那样没水平的话。争论的焦点在于大型企业开发更重要的是框架和平台，而非语言。不知道 你们从什么地方看出来我说RoR不能开发这些框架之类的意思？ 搞大型网站的人更关注性能方面的技术，搞大型企业开发的人更关注系统构架方面的技术 。如果ROR 粉丝们喜欢用ROR企业开发，那我也祝你们好运。 标红为向不应该成为话题的话题5转移。 后来 ltian 写道 我用RIA+Java开发企业应用。等你用了RIA后再看ROR吧。祝你好运。
后来 liusong1111 写道 RIA、ROR、javascript、ruby、java都处于什么层面、什么领域、解决什么问题
的，它们之间是什么关系，连这个都搞不清楚，只能回祝你好运了~ 不懂不是错，一点不懂还煞有其事指指点点，尊重你的才会（假意的）客客气气的说你孤陋寡闻，照东北 话说，您这就是扯犊子啊~ 系统构架解决的是什么问题？通过什么手段解决的？ 能不能想明白这些，也只能祝你好运了。 洗洗睡吧 这是我针对想漂移到话题5的扼杀。 于是 ltian 写道 我讨论的是大型企业应用开发的难点，我强调了框架的重要性，强调企业开发的难点。
我强调企业开发需要一整套的开发体系，我有说过ROR不能开发企业应用吗？ 转了一圈，绕回话题2。 ltian 写道 我强调大型企业开发和语言是否精炼无关。你们看不懂汉字还是心虚啊？
绕回话题1。 ltian 写道 rail里面MVC中的V的开发快捷吗？
ltian 写道 既然要解决V的问题，如果要进行企业开发，你们还是好好考虑我说的人机界面的需求吧
。给大家看个V吧。我觉得Java在这方面也做得不好。我不用Java作为V。我认为V是一个 很重要的问题。不论大型还是小型的企业开发。web应用还是要考虑V的问题。 标红看似绕回了话题3，然而经前面数人提醒，这开启的是新话题 - 话题6 后来 toostupid 写道 我彻底无语了，我想你真的进错屋子了，但是屋子里面的人没打你，反被你打了几
个不知所谓的闷棍。 火星叔叔马丁 写道 都别装了 你们没看出来Itian是来卖他的RIA吗？
ltian 写道 哦，要是这么说，这里更多人卖ROR呢。我是提醒大家，企业开发没想象中的那么简单。
不应该成为话题的话题7 ltian 写道 忽视人机交互的重要性在企业开发领域会吃苦头的。当然把人机交互看成企业开发的全
部，也是不对的。人机交互是企业应用开发的第一步。这一步过不去，任凭你后台写的多么强劲，用户仍 然认为这系统不好用。 居然在话题7上还可以展开。 后来 gigix 写道 其实，我觉得，企业应用很多时候就不应该瞎搞web client
明明用的人都在一个楼一个内网里 明明有一大堆交互 偏要搞到浏览器里用，做的人累得要死，用的人慢得要死 真不知道是搞什么 ltian 写道 我们两个之间的争论不是在于RAIL能否则做企业开发，而是我不大赞同做大型企业开发
时Rails能够以很大差别减少代码数量。你认为依靠Rails本身语言的简洁，我认为更大地依赖框架的运用 。后来争吵也就是因为这样，很多Rails支持者们没有看清我说的，认为我否定Rails开发企业开发的可能 性。所以口水战就开始了。我是一直做企业开发过过来的，应该算个老程序员了。对我来说，C/S系统升 级到B/S系统中头一个难题摆在我面前的就是UI，也就是View的问题。我对乐观估计形式的兄弟们提出UI 的三个需求，所有非议因此而来。 不过现在我发现用RIA+Java可以有效解决UI的问题。我们的系统已经在试运行，用户反响不错。希望有机 会和大家分享这方面的经验。即便想用Rail做服务器端，我认为企业开发的前端选型还是要慎重。既然大 家觉得Rails那么简洁，我也会抽出时间学的。 居然可以堂而皇之的认为在话题1、话题2、话题3、话题6之间转圈有理。 ltian 写道 哦，我在Rails方面所知不多，听楼主所说的全栈式MVC框架也是很迷糊
，就知道MVC什么意思，我感觉楼主可能想用Rails及相关技术搞定企业开发的客户端。我觉得那个难度可 能很大。 绝倒。。。。。 starfeng 写道 现在的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()
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的方式实现，带来了一些复杂度外，其它的都差不了多少。 可惜还不是可以跑的代码。 starfeng在回贴中提到SOA，是这个贴的话题8。 如果我是ltian，肯定认为你们都疯了，说话太没逻辑了。 |
| 返回顶楼 |
 已被评为好帖! |
|
发表时间：2008-08-27
话题1：语言的能力。是否可以通过划分类和函数，达到代码量的等价小，可维护性的等价高，重用性的等价好？
1tian 写道 这样的数据没有任何意义。因为任何语言，你要是把函数粒度划分的比较细，都可以达到类似的效果。
真的这样吗？ rubynroll在以前讨论的贴中就回答过，传统的封装手段不能达到这个效果，记得说的是closure - 有趣的是，1tian在那个贴也是最积极的回贴者 - 也是用同样的手法玩过转移话题。 gigix的ruby代码，在试图用最小示例说明这个问题。两个回应的人给出都不是等价代码。 另外，假想那段功能，就是一段特定的业务逻辑，绝对没有可能被其它地方重用，即使你把它抽成另外的函数，它的合适位置顶多是该类的private方法（且只被一个public方法调用），不适宜放到再底层的库里。 -- 这种场景很多吧。 Quake Wang给出的stats，是用真实产品做的例证。 反问：用C开发javaeye这样的系统，“你要是把函数粒度划分的比较细，都可以达到类似的效果”，是这样吗？ |
| 返回顶楼 |
已被评为好帖! |
|
发表时间：2008-08-27
话题2：通用框架和组件的能力
1tian 写道 大型系统靠的是通用框架和组件来缩短代码行数，提高系统的稳定性和易维护性，而不是靠语言本身吧？
对gigix的题目和Quake Wang的实证视而不见，而转到这个话题。 语言、库（组件）和框架的大致关系： 语言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还是你自己从头编起。 这里的能力，指“抽象”或“封装”的能力，不是指“原始能力”。 所以，结论是，大型系统靠的既是业务框架和组件，也有通用框架和组件，也有语言，他们共同的能力，来缩短代码行数，来提高系统的稳定性和易维护性。不止是语言本身，但语言也是极为重要的。 ruby语言和rails框架在这方面做的很好。 |
| 返回顶楼 | |
|
发表时间：2008-08-27
话题3： Rails和客户端开发技术是不是互斥的？rails和客户端技术的关系？
1tian 写道 我提三个需求，用Rails能轻松实现，就说明我确实无知，我刚才是胡说，我冒犯了Rails
这个神圣的框架和各位高人。 1. 你用Rails弹出一个有模窗口（做企业应用应该知道有模窗口），然后用鼠标拖动起来移动这个窗口。 从这样窗口上选择一些数据然后再到主窗口上进行显示。 2.一个grid，有20列，屏幕显示不下。要求左边3行固定，剩余列用户可以根据需要左右滚动已能够全部 显示。 3.一个窗口有两个控件，左边一棵树，右边一个gird，要求二者之间可以通过拖动来改变宽度，以适应数 据的显示。 这是企业开发里面对界面的最常见和普通的要求。 1tian 写道 你们那些兄弟宣传Rail开发WEB多强，作页面多么快捷方便的时候和Java也是没有关系啊
。这时候站出来说这是客户端的东西，呵呵。有点意思。 1tian 写道 那你们的Rail凭什么号称自己做web开发很easy？我真是服了各位。被最终告诉我，这些
需求很难，是JavaScript管的和Rail是没有关系。 1tian 写道 我用RIA+Java开发企业应用。等你用了RIA后再看ROR吧。祝你好运。
很明显，rails是服务器端方案。关于服务器端能做（以及应该做）什么不能做什么，客户端能做什么不能做什么，本来应该是常识。 你们都说馒头好，可是俺还是渴死了 - 好吧，俺们这堆土人都假定您知道馒头是解饿的 - 哪怕您小小的咬那么一口，也不至于饿死。 |
| 返回顶楼 | |
|
发表时间：2008-08-27
话题4: 人的能力
1tian 写道 后台业务逻辑开发。这取决于开发人员经验和设计水平，不考虑用存储过程来实现，我
们说说用面向对象的语言来开发业务逻辑，那么做得好与坏，质量的高低，取决开发者的经验，面向对象 设计能力，和使用那种语言关系不大。 这本不应该成为话题。或者应该以一种严谨的方式提出来。 我们在比较两个事物的时候，都会假定环境是一样的。 比如，测ruby和java的性能，都会找同一配置的机器，跑同样的test suit。 现实生活也常如此，只是情况更复杂了。 要比人的能力，那么我们就假定他们用的同一种开发环境。 要比语言的能力，我们就该假定他们是能力类似的人或同一个人。 这也是个常识。 这里也从没有人说，开发者经验的差异不会造成做得好与坏、质量高与低的差异。 为什么不能推出：“做得好与坏，质量的高低” 等于 “开发者能力”和“使用工具”两者的综合作用呢？ 为什么就能推出：做得好与坏，质量的高低，取决开发者的能力（经验和面向对象设计能力），和使用那种语言关系不大？ |
| 返回顶楼 | |
|
发表时间：2008-08-27
话题5: 系统构架的能力
1tian 写道 争论的焦点在于大型企业开发更重要的是框架和平台，而非语言。不知道你们从什么地方看出来我说RoR不能开发这些框架之类的意思？
搞大型网站的人更关注性能方面的技术，搞大型企业开发的人更关注系统构架方面的技术。如果ROR 粉丝们喜欢用ROR企业开发，那我也祝你们好运。 系统构架不止是框架、平台。 rails本身就是库和框架，不是语言。 系统构架是解决什么问题的？ 俺不跟你们这堆土人扯要吃馒头还是面条，还是大饼卷大葱，俺关注的是解饿（肚子咕噜~）。 |
| 返回顶楼 | |
|
发表时间：2008-08-27
1tian 写道 既然要解决V的问题，如果要进行企业开发，你们还是好好考虑我说的人机界面的需求吧
。给大家看个V吧。我觉得Java在这方面也做得不好。我不用Java作为V。我认为V是一个 很重要的问题。不论大型还是小型的企业开发。web应用还是要考虑V的问题。 原来您自始至终在说这个啊。为啥没人看出来呢？他们都疯了。 1tian 写道 我是提醒大家，企业开发没想象中的那么简单
这里没人说它简单。 |
| 返回顶楼 | |
|
发表时间：2008-08-27
liusong1111 写道 1tian 写道 既然要解决V的问题，如果要进行企业开发，你们还是好好考虑我说的人机界面的需求吧
。给大家看个V吧。我觉得Java在这方面也做得不好。我不用Java作为V。我认为V是一个 很重要的问题。不论大型还是小型的企业开发。web应用还是要考虑V的问题。 原来您自始至终在说这个啊。为啥没人看出来呢？他们都疯了。 1tian 写道 我是提醒大家，企业开发没想象中的那么简单
这里没人说它简单。 我也说几句，我感觉Flex 做 View挺好， 只可惜Flash对搜索引擎并不是太友好， 所以只能企业软件大力推荐使用， 什么时候 Flex 能一统天下就好了， 说一下我的理想解决方案： Rails Restful + Flex 3， 但感觉 GDS/BlazeDS + Spring + Hibernate + Flex 3 应该也不错，只是感觉肯定要多写很多代码, 但速度应该会快几个级别 其实用 Eclipse Rich Client Plattform(RCP)的企业软件就我接触的还是很多的， 也是个发展趋势，虽然是C/S老模式， 但是 OSGI 框架符合 SOA 理念，很好解决了 很多问题。 |
| 返回顶楼 | |
