概念

    Revel 通过简单的约定来支持 MVC 设计模式，轻量、开发效率高。

    • 模型 描述基本的数据对象，特定的查询和更新逻辑。
    • 视图 一些模板，用于将数据呈现给用户。
    • 控制器 执行用户的请求，准备用户所需的数据，并指定模板进行渲染。
      一些不错的MVC结构概述，像 Play! 框架 与Revel框架完全匹配。

    请求的生命周期

    下面是一个请求处理的基本流程：

    概要:

    • Filters 链接到一个请求处理链，由水平相关的功能组成，比如请求记录，cookie策略，授权等。大部分内建功能都是由过滤器实现的。
    • Actions 是处理用户输入和产生请求结果的的函数。

    Revel 构建自顶级 Go HTTP server, 他为每一个到来的请求创建一个 go-routine (轻量线程)，用于处理并发。

    默认情况下， Revel 处理程序注册到 接受所有的请求连接。然而, 应用程序可以自由的重写此行为 – 例如, 可以使用现有的 http.Handlers 而不是Revel来重新实现此功能。具体请参考 FAQ。

    过滤器

    过滤器 实现了Revel的大部分请求处理功能，过滤器有一个简单的易于嵌套的接口。

    “过滤器链” 是一个函数数组, 每一个都会去执行下一个，直到最后一个过滤器执行了控制器方法。例如, 过滤器链中的第一个过滤器是 RouterFilter, 它决定哪个操作接受请求并保存到控制器。

    总之, 过滤器和过滤器链就像机架一样。

    每一个 HTTP 请求，执行一个 action, 处理请求并写入响应。 相关的 actions 被分组到 controllers中. 类型包含相关字段和方法，作为每个请求的上下文。

    Controller 是直接 或 间接嵌入 *revel.Controller 的一个struct。

    Action 是 Controller 的方法。符合下面的条件:

    • 名称是导出的（首字母大写）
    • 返回 revel.Result 类型
      例如:

    程序调用 渲染一个模板, 传递给模板一个username参数。revel.Controller 有许多方法处理 revel.Result, 程序也可以自己创建处理方法。

    Results

    Result 符合下面的接口：

    通常, 什么也不响应，直到 action 和所有的过滤器返回。此时，Revel写入响应的headers和cookies。(例如设置会话cookie), 然后调用 Result.Apply 写入实际响应内容。