DSLの全面的な採用

Rubyがそうであるのと同様に、GroovyはDSLを作成するのに極めて適した言語である。DSLとはドメイン記述言語、すなわちシステムが扱う対象を、それに特化した語彙や構文を用い、平明に記述するための専用の言語である。

GroovyではDSLを容易に定義することができ、Grails自身の中でもDSLを積極的に活用している。たとえば、URLマッピングの設定や、ORMのマッピング、SpringのWebFlowの設定などを、それぞれ固有のDSLで直感的に行うことができる。

開発者は、このように開発作業を通じてDSLを使うことで、DSLの模範的な用法や威力を知ることになる。

実用システムへの適用

GrailsはJava EEベースのシステムであり、標準的なwarファイルを生成できるので、実運用時にはそれを適切なJava EEアプリケーションサーバにデプロイして使用することになる。

この際に、基本的にはJava EEで培われてきた性能チューニング、負荷分散等のノウハウや技術がすべて使用できる。

プラグインアーキテクチャ

Grailsにおいて重要な構造の一つが「プラグイン」である。Grailsにおけるプラグインは機能の拡張手段であるが、最近になって、SpringやHibernate連携を含め、中核機能のほぼすべてがプラグインとして実装しなおされた。この結果、事実上、Grailsはプラグインの集合体になったといえる。

プラグインとして組み込まれるモジュールは、前述の更新検出/伝播制御、再読み込みなどの仕組みを持っており、アプリを終了させずにソース修正/実行確認を続けていくことが可能となっている。

Grailsのプラグインはまた、MavenやGEM、aptなどで実現されるような、プラグイン間の依存関係を基にした、構成要素の整合性管理の仕組みを持っている。さらに、設定ファイルを編集したりすることなく、コマンドライン一発でインストールやバージョンアップを行うことができ、「開発の準備時間の削減」や「設定ミス防止」などの効果が望める。

以上より、Grailsのプラグインは、迅速な開発に大いに貢献する機能であるといえる。

フレームワークのディストリビューション

現代の開発において複数のフレームワークを組み合わせて使用するのはもはや常識である。しかし、フレームワークの「乱立」ともいえる現在の状況は、大きな弊害を招いている。優れた技術者なら適切なフレームワークを適宜選ぶこともできるだろうが、経験の浅い技術者にとってそれは決してたやすい作業ではない。そもそも、各フレームワークには一長一短があるため、その選定作業は「正解のない問題」ともいえる。

また、特定バージョンのフレームワークやライブラリを選び出して組み合わせ、それらに対して動作確認を実施して提供するという一連の作業は、Linuxにおける「ディストリビューションの開発」のようなものである。信頼できるディストリビューションがなければ、プロジェクトや開発組織ごとにそれを行なわなければならなくなり、効率低下をはじめとする様々な弊害が生じるのは明らかである。

Grailsコアの構成要素は、いずれも熟考の末選び抜かれた実績あるものばかりだ。もちろん動作確認もされているため、Grailsは実績が確認されたフレームワーク・ディストリビューションであるといえる。