• 2008-08-28

    原生态Rails开发

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/28279545.html

    曾经,我听到了太多关于Rails的评价,不过,只有经历了,才会了解真相,很高兴自己在一个真正的Rails上项目上摸爬滚打了几个月。之前大家大多没有Rails的经验,于是,我们体验到了原生态的Rails开发。

    在我看来,MVC的核心在于M,ActiveRecord是一个很好的起点。

    ActiveRecord用起来非常简单,比如修改一个字段,我们可以这样做:
      def spotlight!
        record.spotlight = true
        record.save!
      end
    正是因为这样做极其简单,所以,对于一组记录而言,就很容易写出这样的代码:
      records.each(&:spotlight!)
    我们知道,上面的保存操作,最终会对应成一条SQL语句,所以,下面的集合操作就会生成很多条SQL语句。只要一提醒,相信大多数都会发现,对那一组记录的操作,一条SQL就可以搞定。

    随着项目的进展,Model文件逐渐增大,里面的代码越来越多,显然,大类是不受欢迎的。我们都知道,Ruby是一种动态语言,一个重要的优势就是它的类可以重新打开。换句话说,对于这种越来越大的类而言,我们是可以把其中的方法按照逻辑进行分离,将其置于不同的文件里面。前不久,和一个做Java的同事在探讨Domain Model如何组织,他也遇到的类似的问题,不过,显然,Java在这方面没有Ruby这样生就的能力。

    用划分文件的方式,显然可以在一定程度上解决Model逐渐增大的文件。不过,对于这个问题,还需要从另外一个角度思考,为什么Model会越来越大。在Java开发中,我们会很明确的划分出Model层和Service层,在Controller中,我们会调用Service层来解决问题。而在Rails开发中,我们通常会直接使用Model,实际上,这等价于把Java开发中的Service和Model的逻辑都放在了Model中,这也是让Model逐渐增大的一个原因。所以,这就给了我们一个机会,Model里面的东西,真的都属于Model吗?也许,在Rails开发中,我们不习惯像Java开发那样严格划分出Service层,但是这并不是说,就应该把所有的东西都放到Model中。所以,当我们一次又一次面对那个越来越庞大的Model时,也许,我们需要做的是做一番设重构,让那部分不该属于Model的代码,回归到它应该在的位置。

    说Model一力承担了Model和Service两个角色应该承担的工作,是一种谬奖。除了Model之外,Controller往往会在功劳簿有浓重的一笔。正如我最开始提到ActiveRecord实在够简单,它的字段都是可以直接在外面访问的,所以,看到在Controller里面直接调用也不应该感到意外。有了开头,后面就会变得顺理成章,于是,一个厚重的Action就此诞生了,同样,我们也由此得到了一个练习重构的好机会。

    Rails功高盖主,于是就出现了Rails程序员不一定对Ruby了解很多的现象。结果就是,Ruby语言的特性并不能得到很充分的应用。比如说,有些helper方法会在不同的页面上起作用,对Rails程序员而言,最直接的反应是在Controller里面声明一个helper。也许把这些方法放在一个Module里面,然后让这些Helper包含这个Module似乎更加符合Ruby程序员的胃口。同样,Ruby有很强的元编程的能力,这个能力显然有助于写出更加简短的代码,但Rails程序员却不见得会充分利用这些特征。

    准确的说,我上面列举出的这些问题,并不是Rails本身的问题,比如前面提到的Model和Controller方面,更多的是一个如何设计的问题,只不过,用Rails这种轻快的工具,杀得兴起之际,往往会忽略这些应该注意的问题。挖下的坑,早晚要人来填,为了他们(也许就是自己)的健康,运用这些工具时,再理性一点!

    分享到:

    历史上的今天:

    交流技巧 2007-08-28
    引用地址:

    评论

  • "Rails程序员不一定对Ruby了解很多的现象"──说得相当到位:P