リソースとテーブルのギャップを飛び越える

論理モデルで実現する

テーブル・ビューを使う方法は、シンプルである一方で、Migrationを使用するために修正が大変になります。モデルの属性は、後に何度も修正することになるので、コード上で変更できる方が良いでしょう。

そこで、次は、モデル側でクエリーを構築し、テーブル・ビューのようなクラスを実現してみます。以降では、このようなモデルを論理モデルと呼び、実テーブルに対応する物理モデルと区別します。

論理モデルを表現する方法の1つは、Rails 3.0で導入されたActiveModelを使用することです。ActiveModelは、validationなどの機能をモジュール化したものです。任意のクラスに、ActiveRecordの機能を持たせることができます。

ActiveModelは、検索条件など、ユーザー入力の抽象化などには、非常に役立ちます。しかし、今回定義したいモデルは、実テーブルに直結するものなので、SQLの型を指定したいところです。そこで、ActiveRecordを継承して、属性とともにSQLの型を指定できるようにする方向でやってみます。この継承クラスの実装例を、次に示します。

上記のクラスでは、abstract_classにtrueを指定することによって、テーブルとマッピングされないようにしています。また、Columnクラスを使用することによって、SQLの型を指定できるようにしてあります。本クラスを継承して定義した論理モデルは、次のようになります。

SELECT文で指定した列と、columnメソッドで指定した列を、一致させるのがポイントです。列さえ同じであれば、UNIONなどを活用した複雑なクエリーでも対応付けられます。また、列の定義がテーブルに関連していないので、次のようにモックを作成することで、テーブル定義のタイミングを遅らせることができます。

著者がよく行うのは、「まずはモックを使用して"保存できないアプリケーション"を軽く作成した上でユーザーに操作してもらい、仕様がある程度固まってからテーブルを設計する」という方法です。これによって、デモのタイミングを前倒しにできます。さらに、以前であれば山のようにできてしまっていたMigrationを、少なく抑えることができます。

上記で定義したSaleモデルを、コンソールから触ってみましょう。

validationが機能しているのに加え、関連なども正常に取れているのが分かります。

ARelで修正する

先述した論理モデルの例では、参照のクエリーを文字列で表現していました。この場合、参照件数が1件や複数といったわずかな違いであっても、同じような文字列をそれぞれ個別に用意する必要があります。

幸い、Rails 3.0からは、クエリーを抽象化したARelと呼ぶライブラリが導入されています。本ライブラリを活用し、既存のクエリーを再利用できるように修正してみます。

ARelでは、次のように、テーブルに対応するオブジェクトを作成して、whereなどのメソッドを組み合わせてクエリーを構築します。

一度作成したら、後付けで条件を追加していけるのがポイントです。JOINするクエリーをあらかじめ作成しておけば、細かな条件を付加して再利用できます。このような方針で参照メソッドを修正した例を、次に示します。

コンソールから試してみましょう。

ARelで表現したクエリーが、正常に動作しているのが分かります。

おわりに

今回は、ActiveRecordを活用した中間層の実現方法として、ビューに対応するクラスを置く方法を中心に説明しました。

注意してほしいのは、やり過ぎは厳禁ということです。気がついたら「画面ごとにビューを実現したクラスを定義してしまって、ActiveRecordの特徴である再利用性が生かされていない」とうことにならないように、気をつけてください。基本的には、まずはActiveRecordの関連などを活用し、どうしてもうまくマッチしない時に、今回の話を思い出すと良いでしょう。

次回は、最終回です。NoSQL関連のトピックを解説します。ご期待ください。