昨天一时兴起就和许老师去新华文轩买了两本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有更深的了解
文章来源:
http://blog.sina.com.cn/u/4a5ca0240100075p