《Rails-Guides》Reading notes eight：Action Controller Overview

 控制器的作用

        Action Controller 是 MVC 中的 C（控制器）。路由器决定使用哪个控制器处理请求后，控制器负责解析请求，生成相应的输出。

控制器命名约定

        Rails 控制器的命名约定是，最后一个单词使用复数形式，但也有例外，如 ApplicationController。例如：用 ClientsController，而不是 ClientController；用 SiteAdminsController，而不是 SiteAdminController 或 SitesAdminsController。

方法和动作

        一个控制器是一个 Ruby 类，继承自 ApplicationController，和其他类一样，定义了很多方法。应用接到请求时，路由决定运行哪个控制器和哪个动作，然后 Rails 创建该控制器的实例，运行与动作同名的方法。

参数

        在控制器的动作中，往往需要获取用户发送的数据或其他参数。在 Web 应用中参数分为两类。第一类随 URL 发送，叫做“查询字符串参数”，即 URL 中 ? 符号后面的部分。第二类经常称为“POST 数据”，一般来自用户填写的表单。之所以叫做“POST 数据”，是因为这类数据只能随 HTTP POST 请求发送。Rails 不区分这两种参数，在控制器中都可通过 params 散列获取

JSON 参数

        开发 Web 服务应用时，你会发现，接收 JSON 格式的参数更容易处理。如果请求的 Content-Type 首部是 application/json，Rails 会自动将其转换成 params 散列

路由参数

        params 散列始终有 :controller 和 :action 两个键，但获取这两个值应该使用 controller_name和 action_name 方法。路由中定义的参数，例如 :id，也可通过 params 散列获取。例如，假设有个客户列表，可以列出激活和未激活的客户。

会话

        应用中的每个用户都有一个会话（session），用于存储少量数据，在多次请求中永久存储。会话只能在控制器和视图中使用，可以通过以下几种存储机制实现：

        所有存储机制都会用到一个 cookie，存储每个会话的 ID（必须使用 cookie，因为 Rails 不允许在 URL 中传递会话 ID，这么做不安全）。

        多数存储机制都会使用这个 ID 在服务器中查询会话数据，例如在数据库中查询。不过有个例外，即默认也是推荐使用的存储方式——CookieStore。这种机制把所有会话数据都存储在 cookie 中（如果需要，还是可以访问 ID）。CookieStore 的优点是轻量，而且在新应用中使用会话也不用额外的设置。cookie 中存储的数据会使用密令签名，以防篡改。cookie 还会被加密，因此任何能访问 cookie 的人都无法读取其内容。（如果修改了 cookie，Rails 会拒绝使用。）

        CookieStore 可以存储大约 4KB 数据，比其他几种存储机制少很多，但一般也够用了。不管使用哪种存储机制，都不建议在会话中存储大量数据。尤其要避免在会话中存储复杂的对象（Ruby 基本对象之外的一切对象，最常见的是模型实例），因为服务器可能无法在多次请求中重组数据，从而导致错误。

        如果用户会话中不存储重要的数据，或者不需要持久存储（例如存储闪现消息），可以考虑使用 ActionDispatch::Session::CacheStore。这种存储机制使用应用所配置的缓存方式。CacheStore 的优点是，可以直接使用现有的缓存方式存储会话，不用额外设置。不过缺点也很明显：会话存在时间很短，随时可能消失。

cookies

        应用可以在客户端存储少量数据（称为 cookie），在多次请求中使用，甚至可以用作会话。在 Rails 中可以使用 cookies 方法轻易访问 cookie，用法和 session 差不多，就像一个散列：

过滤器

        过滤器（filter）是一种方法，在控制器动作运行之前、之后，或者前后运行。过滤器会继承，如果在 ApplicationController 中定义了过滤器，那么应用的每个控制器都可使用。前置过滤器有可能会终止请求循环。前置过滤器经常用于确保动作运行之前用户已经登录。这种过滤器可以像下面这样定义：

        如果用户没有登录，这个方法会在闪现消息中存储一个错误消息，然后重定向到登录表单页面。如果前置过滤器渲染了页面或者做了重定向，动作就不会运行。如果动作上还有后置过滤器，也不会运行。

请求和响应对象

        在每个控制器中都有两个存取方法，分别用于获取当前请求循环的请求对象和响应对象。request 方法的返回值是一个 ActionDispatch::Request 实例，response 方法的返回值是一个响应对象，表示回送客户端的数据。

request 对象:request 对象中有很多客户端请求的有用信息。

response 对象:response 对象通常不直接使用。response 对象在动作的执行过程中构建，把渲染的数据回送给用户。不过有时可能需要直接访问响应，比如在后置过滤器中。response 对象上的方法有些可以用于赋值。