加载中…
个人资料
付老实
付老实
  • 博客等级:
  • 博客积分:0
  • 博客访问:144,270
  • 关注人气:29
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

初窥Ruby on Rails

(2007-02-11 22:43:05)
分类: Ruby/Rails

 昨天一时兴起就和许老师去新华文轩买了两本RoR的书,准备这个寒假专供此道,如果顺利的话,再用它做一个缺陷管理系统的demo出来。

 不过研究了两天发现,直接从RoR入手似乎不是很妥当,应该先学好Ruby,接下来再Rails。不过书已经买了,就硬着头皮搞吧,还好下载了一本Programming Ruby第二版,遇到不懂的可以查阅。

 说说这两天来(准确的说是今天下午到晚上)对Rails这个基于Ruby框架的认识。

 首先它是基于MVC的,这个一点也不奇怪,那么就分开介绍吧

 控制器:

  前端控制器:因为和J2EE的实现机制不太一样,所以前端控制器不向Struts中的ActionServlet那么明显,初步估计是由public目录下的dispatch.*组成的。虽然实现机制可能不同,但是做的事情大同小异。

  应用控制器:类似于JSF中的action,一个应用控制器中可以有多个行为(action)。按照Rails的命名规约,一个应用控制器类必须以Controller结尾,其中的每一个public方法都是一个action。action中可以调用模型进行处理,处理完毕后默认跳转到action同名的rhtml页面(视图),也可以用redirect_to方法跳转到其他视图。
  
  (注:我看的书中并没有区分前端控制器,和应用控制器,这里沿用了Struts中的叫法)

 模型:
  
  模型应该负责提供数据、封装业务逻辑、必要时还需要数据的持久化。先看看在J2EE中模型的实现:
 
  方式1:EJB中的实体Bean
  优点:数据、业务逻辑、持久化功能全部提供,代码少
  缺点:持久化功能不灵活,导致一些业务逻辑难以优雅的实现。需要大量配置文件

  方式2:JavaBean
  优点:简单
  缺点:大量重复的编码

  方式3:Hibernate中的PO对象+DAO对象
  优点:代码少
  缺点:po和dao是分离的,导致“贫血类”,Hibernate自身对事物的管理比较弱。需要大量配置文件,映射对象关系时比较复杂。如加入Spring则会进一步增加代码的复杂度

  可以看到,J2EE中各种模型实现都或多或少有自己的缺陷(其中我最看好的还是实体Bean,希望EJB 3.0能一转2.0的颓势)

  而在Rails中已经使用了ORM,与Hibernate比这个ORM不需要大量的配置文件,只需要遵守命名规约,并在代码中映射对象间的关系。更像EJB 3.0吧。

  Rails中模型的优点在于将数据、业务逻辑、持久化功能放在一起了,并且借助于Ruby强大的继承功能,你并不会觉得模型变得臃肿,甚至更加简单。

  缺点嘛,自然就是刚学的时候有些摸不着头脑,呵呵。

  据说Rails中模型还有一种实现方式,看到后几章再说吧。

 视图:
  视图没有什么好说的,虽然里面确实有一些新东西,比如类似于tiles的layout(布局),神奇般的获取模型中的数据,可以用于取代标签库的helper等,不过这些特性并不至于令人瞠目结舌。

 总结一下,我觉得Rails也没有什么特别神奇之处,当然可能是因为我还刚入门。目前为止最震撼我的是借助于ruby脚本,可以快速根据数据表生成应用控制器、模型、视图(Rails的术语叫scaffold【骨架】),在很短的时间内完成一个CRUD的界面。但是J2EE下的AppFuse也能实现这个功能。

 直到现在我还是固执的认为Ruby的快速开发就在于它提供了更多的api和更多的复杂语法。当然,这是一种成见,希望把这本书看完后会对Ruby和Rails有更深的了解

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有