我々は賢いので。

かんとーちほーのエンジニアの、仕事とか、趣味とか、いろいろなはなし。

Grailsお勉強中。

どめいん。

取り敢えず、目下最大の興味の対象ドメインクラス、という事でドメインクラスまわりのアレをぐぐりまくり。

Grails:Domain

groovy grails domain とかでぐぐってたら、以下のページを見付けたのでザーッと読んでみました。

http://grails.jp/doc/2.3.x/guide/GORM.html

裏っ側でhibernateを利用しているって話がすぐ出て来て「なんだ、前にやってたやつと同じじゃん」と気が楽になりました。

つまり、

Java/EntityManager/Entity → hibernate → でーたべーす

だったのが

Java+Groovy/Grails/Domain → hibernate → でーたべーす

に変わっただけですね。

hibernateJPAJavaEEのORM)に対する参照実装(参考実装、リファレンス実装、つまりサンプル)であり、つまりぼくは今もJPAを使っていたんですね。

JPAみたいなもんだなと思ってたら、JPAそのものでした。

(*'▽') な~んだ!

当然、リレーションが鬼門になる

モノがJPAと言う事が解ったので関連(Relation:OneToManyとか、MenyToManyとか、アレね)のあたりが鬼門なんだろうな、と言うのは予想がつきます。

で、実際、今の開発プロジェクトでは、JPAを最も簡易的にシンプルに利用するパターンで、関連をほぼ使用せず、単純なCRUD操作にのみDomainを利用しているようです。

複雑な場合は素直にNativeQueryを使う、というスタンスですね。

ここはもう、プロジェクト全体のJPAに対する習熟レベルや学習コストとの相談ですからねぇ。

ちなみに、以前やってたJavaEE開発の時も近いスタンスでした。

マジで、関連を使いだすと物凄い難しくなるよね。

問題はアレだ、トランザクション境界

以前はEJBを使っていたので、トランザクション境界がハッキリしてたんですが、今回だとどこにあるんでしょう。

って言うか、その辺を指定するアノテ・・・

あー!!

確か @Transactional ってついてるメソッドがそういやいたな、あそこが若しかしてトランザクションのエントリポイントになるのか?

言ってみればあそこからEJB内だと思えば良いのかな、多分そうだな、そういう気持ちで調べよう。

さーびす。

ここの開発では論理レイヤがかなりテキトーなようで、コントローラとサービスの区別が曖昧っぽい。

なんとなくルールらしきものを読み取ってみると、こんな感じに見える。

  • 業務機能で必要なロジックは基本的にコントローラに直乗せしちまう
  • 機能間で共通的に使用する再利用性のあるロジックはサービスにする

みたいな?

まともな開発規約アーキテクチャ資料無いんで、読解と解釈をベースにするしか無いけど、大筋間違ってないと思う。

Grails:Service

さて、そんなわけで、本来Groovy開発のスタンダードとしては、ビジネスロジックはサービスに乗せるものなんじゃないかと予想。

と思って色々とぐぐってたら、今度はこのページに到達。

http://grails.jp/doc/2.3.x/guide/services.html

Grailsではサービスレイヤの概念を持っています。

再利用や関心事の明確な分離を妨げるといった理由から、Grailsチームは、コントローラ内にアプリケーションのコアロジックを持ち込まないことを推奨します。

だよねー?だよねー?そうだよねー??

そうじゃないかなー、って思ってたんだー、うん。

ちょめちょめさーびす?

と思ってざっとナナメ読みしてたら気になる記述が。

サービスの名前は、規約でServiceで終わることになっており、

(*'▽') ふぁ?

マジ?

かなり昔のテスティングフレームワークのテストメソッドが XxxTest ってメソッド名である事を決められてたように、

Groovyに於けるサービスクラスは XxxService ってクラス名にサフィックス付けなきゃいけないってルールがあるの?

@Serviceマーカアノテーション を使うとかじゃなくて?

型ハンガリアンとか、メタ情報サフィックスとか、それ系の文化あまり好きじゃないんだけどなぁ、、、。

マーカアノテーションやマーカインタフェースの方がよくね?

CoCって言うらしい

こういうのを RailsGrails 界隈の用語で CoC : Convention over Configuration って言うらしい。

すなわちアノテーションだとかXMLだとかで明示的に「設定」するんじゃなくて、 「grails-app/services」配下に「XxxService」って名前で配置するという「規約」に則って動くよ、と。

うーん、、、ぼくはちょっと好きくないなぁ、この思想は。

ソリューション内のどこかしらに明示的に書かれていて欲しい、って気持ちが大きいなぁ。

参考情報:

uehaj.hatenablog.com

(追記)CaC(Convension as Configuration)てのはどうでしょう。

あー、CaCと言われれば物凄いしっくり来るなぁ。

これは凄い参考になったし、凄い納得した。