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

1. 你用Rails弹出一个有模窗口（做企业应用应该知道有模窗口），然后用鼠标拖动起来移动这个窗口。从这样窗口上选择一些数据然后再到主窗口上进行显示。
2.一个grid，有20列，屏幕显示不下。要求左边3行固定，剩余列用户可以根据需要左右滚动已能够全部显示。
3.一个窗口有两个控件，左边一棵树，右边一个gird，要求二者之间可以通过拖动来改变宽度，以适应数据的显示。

其实，我觉得，企业应用很多时候就不应该瞎搞web client
明明用的人都在一个楼一个内网里
明明有一大堆交互
偏要搞到浏览器里用，做的人累得要死，用的人慢得要死
真不知道是搞什么

很好很强大！cobol程序员都被雷死了。

 

 稳定性,成熟度,资源，这也是J2EE最后的一块遮羞布，要比这些我更看好MFC，结果世道变了，MFC的稳定性,成熟度,资源已是昨日黄花。

 

最近校内采用rails+flex开发新的系统，我拭目以待，至于兼容性我想每个语言都有，相对于php从4-5，我觉得rails要好多了。

 

 

 

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

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

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

语言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还是你自己从头编起。

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

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

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