Grailsを味見してみた
気まぐれに技術系のエントリ。Grailsを触って感じたメリットやデメリットのメモです。
ちなみに「味見」とは「フレームワークの闇を見ない」ことを意味しております。ちょいちょい仕事でフレームワークやアーキテクチャの選定結果なんぞをレビューするようになってきたので、メリットすら感じたことのないフレームワークを少しでも減らしておこうと。目的が目的ですので、Grailsでサバンナに生存競争する気はありません。
環境を作ってIntelliJにプロジェクトをオープンするまで
環境作るのはあまりごちゃごちゃ考えずにgvm使いましょう。GroovyもGrailsも良きに計らってくれます。
gvmのインストールは公式見れば良いので省略します。gvmインストールしたら、
> gvm install groovy
と
> gvm install grails
をおもむろに叩けばGrails環境の出来上がりです。簡単ですね。
環境ができたら適当なディレクトリでプロジェクトを作ってみます。
> grails create-app helloworld
名前の通りrailsっぽい感じで簡単ですね。プロジェクトのディレクトリがカレントに作られているはずです。
もちろんVimもEmacsも使えない情弱なので、IntelliJにお世話になります。
このときに「File -> Open」でプロジェクトのディレクトリを開かないように注意して下さい。プロジェクトが上手く読み込まれません*1。Grailsの公式ドキュメントにも書いてある通り「File -> Import Project」からbuild.gradleを読み込んで下さい*2。
プロジェクトの初回インポート時には依存関係のあるライブラリを参照しにいくので、ロードに時間がかかる場合があります。Scalaのコンパイルしかけてファンがぶおんぶおん鳴りだすよりはちょっとましです。おとなしく待ちましょう。
grailsコマンドを使ってみる
Grailsプロジェクトに対する操作はgrailsコマンドを使って行います。
まずは grails help
を叩いてみましょう。grailsコマンド利用可能なコマンド一覧が出てきます。数は多いですが味見に必要なコマンドは3種類しかありませんので、個別に説明していきます。
createなんちゃら
Grailsが管理するコントローラやらドメインモデルやらビューやらを作ります。関連する物がある場合は一緒に作ってくれるので、IDEで個別に作るよりはこのコマンドを使った方が楽です。createなんちゃらコマンドで作れる対象は以下です(help基準)。
- create-controller
- create-domain-class
- create-interceptor
- create-script
- create-service
- create-taglib
- create-unit-test
- create-functional-test
- create-integration-test
serviceやinterceptorあたりはGrails独自の文化(というかJava系の文化)を感じさせます。
generateなんちゃら
生成されたドメインモデルを元にドメインモデル操作のために必要なソース一式、もしくはコントローラを生成します。
- generate-all
- generate-controller
railsのscaffoldに近いですが、ドメインモデルを先に作っていないとコマンドがエラーになります。railsと同じくskinny controller, fat modelに近いとは思いますが、ドメインモデルをtoo fatにさせたくないという思想を強く感じます。ドメインモデルは永続化層のためのインターフェイスに専念させたいようです。
run-app
アプリケーションを実行します。今回はとりあえずdevelop環境で動けば良かったので、パラメータは何も指定せずに実行しています。ドキュメントを見る限りgradleのrunタスクを実行しているだけっぽいので、IDEA上で実行設定を作れそうな気もしたのですが、Terminalあるしあんまりコマンド叩くのもあまり変わらなかったのでそこまで突っ込んでやっていません。
雑感
感じたことをつらつらと。
domain層
JPA由来のAPIとrails由来のAPIがあるので、両方ともある程度予習しておいた方が良いかと思いました。メソッド表現形式を使ったDynamic FinderとかどことなくJPARepositoryっぽさがあります(railsにもあったっけ?)。使い勝手については、ActiveRecordにも当然近いんですけど、S2JDBC的に感じました。結構わかりやすく書けそうで好みです。機能的にはやっぱり永続化層に近いですよね。
service層
サービス層があるのは良い感じです。railsはどことなくtoo fat modelになりそうな気がしていて、永続化の部分とビジネスロジックを分けることをフレームワークが示唆している。かつメリットがないレベルの大きさなら使わなくても良い、というアプローチも用意してくれているのはありがたいです。
ちなみに、サービスは何もしなくても勝手にトランザクション境界になってくれる模様。
railsっぽくない所も良い
resources.groovyで規約から外れたパッケージやクラスもロード可能なところは、設定ファイルでどうとでもなる(ただし見通しは悪くなる)railsっぽくない感じも許容してくれていて好きです。アプリケーション実行時のスクリプトなんかも生成されているので、最悪フレームワークの周辺もゴリゴリとチューニングしたりできそうな気がします。踏み込みすぎるとGrailsのバージョンアップで死にそうな未来が思い浮かびますが、杞憂ですかね?
テストについて
テストフレームワークはSpockなんですかね。ちょっと公式の記述がよくわからなかったです。
createなんちゃらでコンポーネント生成するときにパッケージべたに置くのはちょっとやめてほしいところですね。。。コントローラやらドメインやらサービスやらのテストが全部同じレベルにあって見づらいです。
まとめ
railsっぽくない使い方も十分に許容しつつ、railsっぽい開発もできる感じがします。最初はrailsっぽく使えば良いんじゃないですかね?
とりあえずGrails味見は終了です。Intel Galileoを安く入手できたので、自宅サーバ作ってみたりして遊びます。