Grailsとrailsの違い

GrailsとRailsの違いとして、細部や、あとプラグインの充実度とか、開発者数とかいろいろありますが、私見としては、技術的に一番大きいのは、以下の点です。

• （Ａ）GrailsはドメインモデルをGroovyクラスで作って、それがＤＢに（裏で自動的に）マッピングされる、というものです。ORマッピングの普通の形。つまりドメインモデル中心。基本的なレベルではＤＢスキーマ定義は意識する必要はありません。

• （Ｂ）しかしRailsではテーブル定義は別に行います。つまりスキーマ中心。定義したテーブルはRubyオブジェクトとしても見えてくるのですが、ある意味派生的というか、便宜的というか。フィールドひとつ追加するにせよ、ＤＢスキーマを意識しないわけには行きません。

この違いには哲学的な面もあるのでしょうが、この方針の違いを生んでいる実際的な理由のひとつとして、ベースとなる言語RubyおよびGroovyの間の機能の差が挙げられると思います。具体的には、Rubyには変数に型がありませんが、Groovyにはそれに型をつけることができる、という差です。

（Ａ）のようなやりようは、変数から型を読み取りようが無いRubyでは、クラス定義からＤＢテーブルに自動マップすることができないのでやりたくてもできません。なのでRailsでは、しょうがなくＳＱＬのテーブル定義情報からフィールドの型情報を使用することになります。さらに、記述情報の分散を防いだり、DRY原則のために、テーブル定義すべてが開発者の手にゆだねられます。この結果、ドメイン設計者はＤＢテーブルという実装詳細を開発の最初の時点から扱わなければなりません。

方や、Groovyは変数に型を指定することと、しないことの両方の使い分けができます。ドメインモデルクラスを定義する際には、このフィールドの型を指定するスタイルを用います。具体的には、

class Author {
String name
int age
}

みたいに書きます。以下はGroovy的にはＯＫですが、ドメインクラスとしてGrailsで永続化(ORマップ)する場合には使えません。

class Author {
def name
def age
}

ＧｒａｉｌｓのＯＲマッパ（ＧＯＲＭ）はこの型情報などを最大限有効に使って、テーブルの定義を内部的に自動的に生成します。これによって、ドメインモデルの設計者は、ドメインクラスの論理的設計に集中することができます。

もちろん、両方式にはさまざまな得失があります。Hibernateを通さねばならないGrailsよりもテーブルを直接いじれるRails方式の方がチューンナップには有利かもしれません。とにかく一概にはどちらが良いとはいえません。

ただ、Ｇｒｏｏｖｙ言語の特徴である「動的・静的タイピングの両方可能で適宜使い分けるスタイル」が、Ｇｒａｉｌｓの骨格的アーキテクチャである（Ａ）を実現するために有効に働いているとはいえます。

補足
　補足するまでもありませんが、RailsもRubyも、いずれも革新的なアイデアに基づいたプロダクトです。Grails/Groovyはそれらから甚大な影響を受けており、多くの場合にそのまんまパクッてもいます。上は、それを当然踏まえたうえで、技術的に何が違うか、という話。