|
|||||||||||||||||||||
| 1 2 3 次のページ | |||||||||||||||||||||
| はじめに | |||||||||||||||||||||
|
前回より、Groovy上で動作するRailsライクなフレームワークである「Grails」と「Rails」について比較をしています。今回はモデルについて比較するとともに、その他にも気になる点をまとめました。 |
|||||||||||||||||||||
| モデルの比較 | |||||||||||||||||||||
|
では、さっそくモデルの比較を行います。 |
|||||||||||||||||||||
| スキーマ管理 | |||||||||||||||||||||
|
RailsでもGrailsでもテーブル名とモデル名およびカラム名とフィールド名について命名規約に従うことで、自動的にO/Rマッピングが実施されます(表1)。
表1:O/Rマッピングを自動化する規約 ただし、GrailsとRailsのモデルを比較すると、スキーマ情報をクラスで一元管理するのか、テーブルで一元管理するのか、という点がかなり異なります(表2)。
表2:RailsとGrailsのスキーマ管理比較 Railsではスキーマ情報はmigrationなどの機能を用いて、テーブルで管理します。RailsのActiveRecordがテーブル構成を自動的に読み取り、クラスにデータへのアクセッサメソッドを動的追加しています。 Grailsでは逆にクラスでスキーマ情報を管理しています。クラスに宣言したフィールドが解析され、サーバ起動時に必要に応じてテーブルが生成・更新されます。 クラスでスキーマ情報を管理することのメリットとして、Groovy上ですべての記述が完結し、シンプルな構成になることがあげられます。 一方、今回調査した範囲では各カラムの大きさやインデックス付与の指定をする方法は見つかりませんでした(注1)。これは性能面に致命的な悪影響を与える可能性があるため、今後アノテーションなどで任意に指定できることが望まれます。
※注1:
Grailsではテーブルの自動生成をOFFにし、自前でテーブルを定義すれば上記の問題を解決できますが、その場合スキーマがSQLとクラス定義で2重管理されてしまいます。
|
|||||||||||||||||||||
| リレーション | |||||||||||||||||||||
|
Grailsではテーブルとテーブルのリレーション指定をRailsに近い形式で記述できます。リスト1ではrelatesToManyという記述でCarとWheelの1:nのリレーションを記述しています。 リスト1:1:nリレーションの記述
class Car {
記述できるリレーション指定をまとめたのが表5です。 Railsでできることの大半はGrailsでもできますが、唯一n:nのマッピングについては今のところ未対応のようです。Grailsは内部でHibernate(JavaのO/Rマッピングフレームワーク)を利用しており、Hibernateではn:nのマッピングが実現されているため、早晩対応されることが予想されます。 また、継承関係にある複数のクラスを1テーブルにマッピングする(Single table inheritanceと呼ばれる)ことはRailsでもGrailsでも実現されています。
表3:Grailsのリレーション記述一覧 |
|||||||||||||||||||||
|
1 2 3 次のページ |
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||

