これからはじめるRuby on Rails

RESTfulアプリケーションへの応用

ここまでは、アクティブ・レコード・パターンを使用した時の、一般的な注意点を述べてきました。以降では、Railsアプリケーション特有の注意点について説明します。

HTTPメソッドを有効に活用してリソース操作を表現する「REST」（Representational State Transfer）が注目されていますが、RailsではREST対応が標準となっています。設定を1行書くだけで、表1に示したように、URLとコントローラの対応が自動的に設定されます。

表1: ユーザー・コントローラ（user）に対して設定されるマッピング

もちろん、独自のアクションを定義することもできます。しかし、やりすぎると設定が複雑になるほか、ActiveRecordの継承クラスとコントローラの間の境界があいまいになってきます。このため、最初のうちは、表1に示したアクションだけで設計する、という縛りを入れた方が良いと思います。

これは、言い換えると、世の中のすべての活動を、詳細表示／一覧表示／新規作成／更新／削除、の5種類の操作に置き換えることを意味します。

「すべての活動を、詳細表示から削除までの5種類の操作に対応付ける」。このようなことはできない、と考えてしまうかもしれません。しかし、一度コツをつかめば、スラスラとできるようになります。いくつか、具体例を見ていきましょう。

例えば、よくあるログイン処理は、「ユーザーというリソースのログインという操作」ではなく、「セッションというリソースの新規作成」と考えるのが、Rails風です。

図3に示すように、前者では、ユーザーのCRUD（Create、Read、Update、Delete）に、ログアウトといったアクションが付加されるので、コントローラが巨大化していきます。一方、後者では、ログイン関連の操作をユーザーから分離できます。

ほかの例としては、検索処理は「パラメータが与えられた特殊な一覧」と考えることができます。前ページで示した商品の販売は、「販売の新規作成」とみなすことができます。

この発想に慣れるためには、「目の前の活動が、何のリソースに対する詳細表示／一覧表示／新規作成／更新／削除なのか」を考えるクセをつけると良いでしょう。あるいは逆に、「実装していないほかの操作が、現実世界では何に対応するのか」を考えるクセをつけると良いでしょう。例えば、「販売」の削除は、現実世界ではどのような行動に対応するでしょうか。考えてみてください。

補足として、上記のリソースをDBのテーブルで実現する際には、動名詞系のリソースを交差テーブルとして表現すると、実装がシンプルになります。覚えておきましょう。

特に、1対多の関連を持つテーブルは、一般には、図4のように外部キーを持たせて定義しがちです。この場合、所属コントローラは、2つのテーブルを参照する必要があります。

一方、図5のように、交差テーブルを間に設けると、コントローラとテーブルが対応付いて、所属テーブルのみの参照となります。見た目は、多対多と同じ構造となりますが、交差テーブルの片方の外部キーにユニーク制約を設けるだけで、1対多の関連となります。

このように、「社員が所属する」という行為は、「会社と社員の関連テーブルである所属テーブルにデータを作成する」という行為である、という発想の転換が、Railsアプリケーションの設計において、非常に重要になります。

おわりに

第1回では、ほかの言語の匂いがするコードを「RUBAIコード」と定義し、そうならないための設計時の注意点を述べました。これは、著者自身が何度も何度も失敗しながら、さまざまなコミュニティから教えてもらったことであり、Javaからの移行時に一番最初に聞きたかった話でもあります。

実際のところ、Railsでトランザクション・スクリプトなどを用いることが間違いかというと、チーム構成や目的に応じて変わるので、一概には言い切れません。ただし、それでも、従来のフレームワークの設計手法しか知らない場合と、Railsの王道を知った上であえて選択する場合とでは、異なります。「守」「破」「離」と進んでいく方が良いでしょう。

次回からは、ActiveRecordの使い方を、コードを交えて解説します。ご期待ください。