RoR企业应用实践之一：移植物资管理系统

前些日就打算开展RoR的实践活动了，见前文“在rails中，多个字段关联同一张表如何做？ ”。在此感谢众热心道友的支持，尤其是sun201200204 的代码圆满地解决了问题。

近两月忙于家事和单位上的诸多琐事，一直未得空闲。近日工作生活终于有点闲暇，才得以静下心来付诸实施。经过近两周的工作，终于大体上完成，算是笔者在RoR上第一次重要的实践，就谈几点体会吧：

1、RoR开发这种中小系统，对于熟悉了Spring+Hibernate+XXX的程序员来说，的确效率惊人。笔者基本上是单干，当初用Spring+Hibernate+JSF作开发的时候，耗掉了两个月左右。除去建模、业务逻辑所耗去的近三周时间外，RoR仍有将近3倍的开发效率(考虑到笔者对RoR的熟悉程度有限)。细下想来，以前用Java开发多浪费的时间依次为：1、配置及布署；2、错误查找；3、多写的代码。其实RoR的ORM、MVC思想与Java是一致的，差别就在于动态语言的优势。所以Ruby可以说是“动”起来的Java。

2、个人感觉RoR的Model这一层比Java中的ORM更上一层楼。简单、直接、清晰，更加适合快速建模与业务逻辑的调整、修改。从这个角度来说，RoR其实是应当在企业实用中发扬光大的。企业应用中，业务逻辑的复杂与混乱历来是个大问题，用RoR的Model来进行建构与变更是相当高效的。

3、企业应用中，很多是联机事务应用，需要快速的界面响应性，这类应用需要用Ajax甚至Flex作表示层来解决。笔者对JS和Flex基本上是生手水平，今后将通过自修及培养其它同事来解决View这层的问题。

经过慎重的实践，笔者现认为RoR是有足够的实力在中等规模的企业应用中获得成功，今后将继续努力的脚步。在此与诸位共勉。

 

RoR的Model只是用起来便利而已。它用的ActiveRecord不能算是一个真正的ORM，功能比Hibernate差了很多。而在企业应用中很可能会需要一个真正的ORM，那时候RoR会觉得比较累。你的项目不需要它，很幸运。

楼主遇到的需求比较简单吧，物资管理系统很烦琐。

比较复杂烦琐的业务逻辑，个人感觉还是SQL来得快(虽然不够OO)，项目中使用find_by_sql很爽，提出来的字段可以直接作属性访问，非常舒服。
RoR是相当实用主义的，以实用至上的观点加以应用还是很好的。以本人现在的RoR水平，暂且定位在中小系统吧。

至于功能，必须要用到Hibernate甚至EJB的时候再用吧。

那显然不是这样。实现同样的功能，用Java需要写的代码量就是会有Ruby的三到五倍以上。代码越少越好，这个道理是永远不变的。

“以前用Java开发多浪费的时间依次为：1、配置及布署；2、错误查找；3、多写的代码”
不是太明白：
1、配置及布署：用java的话（其实用任何技术），这个步骤不会占用多少时间吧；
2、错误查找：你现在用ror可以省去了？
3、多写的代码：比较代码绝对数量没有意义，分层和架构的好坏对开发和维护影响更大，毕竟敲字符所用的时间只占整个开发周期的很小部分

1、配置问题是很大程度上是由Java的自由所带来的，把各种框架和表示层技术配在一起，再配置应用服务器，加上配置IDE，相当地耗时并且容易出错。
还有动态语言即时更改即时生效的特点，不是静态编译语言能够比拟的，即使是热布署也不容易完全达到。

2、个人感觉RoR报错的信息比JSP明确得多，大多数情况下能够根据提示的代码文件、出错的行数和出错的提示信息找到问题所在，查错要快得多。

3、RoR的分层和架构代表了当前B/S系统的最佳实践，加上REST后更是如虎添翼，异构集成与多种客户端兼容逐渐不成问题，可以放心使用了。如果能严格遵循TDD，代码的质量和维护也有保证。这样下来省去近一半的代码量就相当可观了。

唯一不爽的是rails的Document写得太简略，不便初学者使用，如果能像programing ruby一样带上示例代码就好了。

谁告诉你RoR本身的分层好了？连个service层都没有……别告诉我你不需要！你要是不需要，说明你那点东西根本不需要那么复杂的框架……

……
愤青了？
你要一个所谓的“service层”来干嘛？

每个业务流程都应该是一个service的方法，而这些方法并不单单属于某一个model，所以他应该是另外一个service层

BTW:为什么我再一个controller的方法里面再render :action，那个方法的所有instance variable不起作用？