Ruby on Rails也是一个MVC框架

中关村村草

Ruby on Rails也是一个MVC框架

回想1979年，Trygve Reenskaug提出了一种开发交互式应用的全新架构。在他的设计方案中，应用程序被分为三类组件：模型、视图，以及控制器。

    模型（model）负责维持应用程序的状态。模型携带数据，但又不止是数据，它还负责执行施加于这些数据之上的业务过则。

    视图（view）负责生成用户界面——通常会根据模型中的数据来生成。

    控制器（controller）负责协调整个应用程序的运转。接收外界的事件，与模型交互，并将视图展示给用户。

    这个三位一体的组合——模型、视图和控制器——构成了一个架构模式，那就是著名的MVC。

    Ruby on Rails也是一个MVC框架。Rails强迫你将应用程序按照模型、视图和控制器进行划分，并遵循这一结构分别开发各部分的功能。当程序运行时，Rails会把各个部分组装在一起。Rails的有趣之处在于：“组装”的过程默认地按照人们常用的命名惯例来进行，因此，一般情况下你不需要编写任何外部的元数据配置信息。这正是Rails一以贯之的“惯例重于配置”观念的体现。

    在一个Rails应用程序中，进入的请求首先被发送给一个路由组件，该组件判断应该将请求发送到应用程序的什么部分、如何解析这一请求。这一阶段将找出控制器代码中的某个特定方法，要求它来处理请求（用Rails的行话，这个方法叫做“action”）。action可以查阅请求中携带的数据，可以与模型交互，也可以调用别的action。最后，action会为视图准备充分的信息，视图则将所需的信息展现给用户。

    下图展示了Rails处理一个请求的全过程。在这个例子中，我们假设应用程序已经向用户展现了一个“产品分类列表”页面，用户则点击了某个产品旁边的Add To Cart（“放进购物车”）按钮。这个按钮链接到我们的应用程序，URL是http://my.url/store/add_to_cart/123，其中的“123”是所选商品的系统内部ID号。




路由组件收到来自外部的请求之后，立即将其拆成小块。简单来说，它把路径的第1部分（“store”）看做控制器的名称，第2部分（“add_to_cart”）看做action的名称，最后一部分（“123”）则按照惯例被放入一个名为“id”的内部参数。进行这样的分析之后，路由组件就知道：应该调用StoreController这个控制器类中的add_to_cart()方法。

    add_to_cart方法会处理用户的请求：找到当前用户的购物车（这也是由模型惯例的一个对象），请求模型找到编号为123的商品信息，然后告诉购物车将该商品加入其中（请注意模型是如何跟踪所有业务数据的：控制器只是告诉它做什么，而模型自己知道该怎么做）。

    现在，购物车中已经放入用户选择的商品，我们需要将这一事实展现给用户看。控制器会安排视图访问模型中的购物车对象，并调用视图代码使之呈现在用户眼前——在Rails中，这一调用通常都是隐藏在幕后进行的。对于特定的action，Rails将根据命名惯例自动为其查找一个特定的视图。

    这就是一个MVC web应用的全部家当了。只要遵循一定的命名惯例，并且合理划分功能，你会发现编写代码边的轻松愉快，你的应用程序会更具扩展性、可维护性。

    如果MVC仅仅是“以某种方式划分代码”的话，你可能会想，那还要Ruby on Rails这样的框架干什么？答案很简单：Rails帮你搞定了所有低级的基础代码——所有那些需要耗费你大把时间去处理的繁琐细节。它让你能够专注于应用程序的核心功能。


转：Ruby on Rails 学习网

2gua

RoR的MVC，是其标志性特性。