トップダウン vs. ボトムアップ
「Grails」
にはかなり興味を持っているのですが、感覚的にどうも受け入れがたい点があります。それは、クラスによってスキーマ情報を管理しようとしている点です。
このようなトップダウン的なアプローチは、サンプルプログラムを素早く作成するのには適していると思いますが、本格的なシステムで使用するにはあまりにもリスクが大きいように思われます。特に業務系のシステムにおいては、アプリケーションよりもデータベースの方がはるかに生存期間が長いので、多くの場合はボトムアップ的なアプローチの方が適しています。
「Trails」 においても、「Grails」 と同様のトップダウン的なアプローチが採用されていたように記憶しています。本家の 「Ruby on Rails」 においてはこのような手法を取っていないのに、何故でしょう？勝手な想像ですが、もしかしたら 「Ruby on Rails」 への強い対抗意識が、不自然なバイアスとして作用したのかもしれませんね。独自性にこだわるあまりに、オーバーランしてしまったというか...。そんな感じがします。
なお、「Hibernate」 を使った開発では、次の４つのタイプの開発プロセスが想定されています。
-
Top down：
既存のPOJOをベースに、マッピング・ファイルやデータベース・スキーマを生成する方法 -
Bottom up：
既存のデータベース・スキーマをベースに、マッピング・ファイルやPOJOのスケルトンを生成する方法 -
Middle out：
マッピング・ファイルを生成し、そこからPOJOスケルトンやデータベース・スキーマを生成する方法 -
Meet in the middle：
既存のJavaクラスと既存のデータベース・スキーマを結合する方法
関連情報
・[ThinkIT]
第7回：RailsとGrailsの比較（後編）
・takeuchi
Nikki - 2005-11-19
・hibernate.org
- Development Process
・Hibernateボトムアップ開発プロセス
（09/12 追記）
「Grails」 「Trails」 及び 「Sails」
では、永続化のために 「Hibernate」 を使用しています。
このため、「Grails」の標準である
「GORM（Grails Object Relational Mapping）」 ではなく、直接
「Hibernate」によるORマッピングを行うことによって、上記の問題を回避することは可能です。
Entries (RSS)
