 |
||||||||||||||||
|
||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| はじめに | ||||||||||||||||
|
前回までで、一通りJavaフレームワークとRailsの比較をしてきました。本連載の最後の比較は、少し趣向を変えてGroovy上に作成されたRailsライクなフレームワークGrailsとRailsの比較をしていきます。 |
||||||||||||||||
| Grailsとは | ||||||||||||||||
|
GrailsはGroovy（Java公式仕様として策定が進められている、JavaVM上で動作するスクリプト言語）上で動作するRailsライクなフレームワークです。当初、Groovy on Railsという名称で作成が進められていたことからもわかるように、Railsに強く影響を受けていることが公言されています（後にRails作者の要請により改名）。 Groovyは豊富なJavaライブラリの利用が可能な上、言語設計自体もRubyの影響を受けているためRailsライクなフレームワークと相性がよいと考えられます。 Grailsに関する情報源には次のサイトがあります。 なお、今回はGrails 0.2系を取り扱います。 |
||||||||||||||||
| アーキテクチャの比較 | ||||||||||||||||
|
図1がRailsとGrailsのアーキテクチャを比較したものです。参考として一般的なJavaEE開発のアーキテクチャも掲載してあります。  図1：Rails、Grails、JavaEEのアーキテクチャ （画像をクリックすると別ウィンドウに拡大図を表示します） RailsとGrailsの最大の相違は、Railsはコントローラから直接モデルを扱っているのに対し、Grailsではサービスクラスをはさんでいる点です。 構成が多少冗長になりますが、Webリクエストなどに影響されないサービスクラスによってテスタビリティが高まる効果があります。逆に、GrailsとJavaEEを比べるとDAOなどのクラスは省略され、Railsと同様にドメインモデル自体がDBへのアクセスメソッドを持つ構成（ActiveRecordパターン）となっています。 結論としては、RailsとJavaEEの中間的な位置づけのアーキテクチャであるといえるでしょうか。 |
||||||||||||||||
| ジェネレータの比較 | ||||||||||||||||
|
続いて、ソースコードの雛形を自動生成する「ジェネレータ」について比較します。 Grailsでは表1に示したジェネレータコマンドが付属しています。
表1：RailsとGrailsのジェネレータコマンド
表1をみてもわかるように、Railsとほぼ同様のジェネレータが準備されているといえます。 なお、GrailsではHSQLDBというサーバ立ち上げ不要なJava製の簡易RDBが同梱されており、プロジェクトをジェネレートするとデフォルトで利用設定が完了しています。そのため、データベースサーバの設定さえすることなくアプリケーションを作り始めることが可能です（ただし、実運用に耐えられる製品ではないため、開発が進んだ時点でRDBの切り替え作業が発生します）。 参考として、ジェネレートされたプロジェクトのディレクトリ構成を図2に示します。  図2：Grailsプロジェクトのディレクトリ構成 |
||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
