uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかReactとかFregeとかJavaとか -

Grailsとrailsの違い

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

  • (A)GrailsはドメインモデルをGroovyクラスで作って、それがDBに(裏で自動的に)マッピングされる、というものです。ORマッピングの普通の形。つまりドメインモデル中心。基本的なレベルではDBスキーマ定義は意識する必要はありません。
  • (B)しかしRailsではテーブル定義は別に行います。つまりスキーマ中心。定義したテーブルはRubyオブジェクトとしても見えてくるのですが、ある意味派生的というか、便宜的というか。フィールドひとつ追加するにせよ、DBスキーマを意識しないわけには行きません。


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


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


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

class Author {
String name
int age
}

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

class Author {
def name
def age
}

GrailsのORマッパ(GORM)はこの型情報などを最大限有効に使って、テーブルの定義を内部的に自動的に生成します。これによって、ドメインモデルの設計者は、ドメインクラスの論理的設計に集中することができます。


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


ただ、Groovy言語の特徴である「動的・静的タイピングの両方可能で適宜使い分けるスタイル」が、Grailsの骨格的アーキテクチャである(A)を実現するために有効に働いているとはいえます。

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

広告を非表示にする