Slim3 for GAE/J ひがさん

本エントリは、エントリ「JJUG CCCいってきました」の一つです。

（補足）のところが主に自分で考えたところ。でも他にも暗に補完してると思うのでそこんとこよろしくお願いいたします。

Threadが使えない
ContextClassLoaderが使えない
セキュリティが厳しい。seculity.policyの設定が厳しい。
- → Spring 2.5からコンポーネントスキャンというのをやってアノテーションを読み取るのだがそれは動かない。
- Struts2の式言語はOGNLを使うがセキュリティマネージャを設定していると駄目
  - → nullにすれば良い
ファイルに書き込みできない
- Apache Commonsのファイルアップロードはテンポラリファイル書き込みがデフォルトなので動かない。Commons upload 1.2.1では、なんとかイテレータ使えばメモリ上でストリーミング取得できる。

従来、セッションはメモリを食うから多用するなというのが常識だったが、GAEのセッションはMemcacheサービスを介してBigTableに保存される。ので、どしどし使っていい（かも）。

高度なことをやればやるほどローカルと本サーバの違いに遭遇しやすい。
DIもなくていい
- でもテストは？
  - → アプリのレイヤで試験の仕組みを作り込まなくてもGAEがある程度サポートするのでDIがなくても試験はやりやすい。たとえばGAEでは
    - ローカルでクエリできる。
    - スタブ（モック）の仕組みをGAEが既に持っている。
    - BigTableはローカルではある種のメモリ上DBで動作するのでデータの消去が簡単。
    - 実環境上ではGoogleアカウント、ローカル環境ではあるアカウントを表すクラスにスタブ（モック）される。
スキーマのマイグレーションはいらない。なぜならスキーマがないから。(補足)
ORマッピングやDBの差異に関する相当な問題が解決される。(補足)
FWないので見通しが良くなる
FWなしでも生産性低くならない。
ただ、上記は「現在の」GAE/Jが、プレビュー段階でありドキュメンテーションおよび機能が成熟していないことによる。現状では高機能なFWではまって問題追求するようなコストがかかるので、それをさけるための判断として、である（長期的にもこうであるとは限らない。）

Slim3はSpring対応だったが、Slim3 for GAEはSpring使用しない。
AOPなし、DIなし。
（ローカル実行時の）ホットデプロイはコントローラのクラス(ActionClass)のみに限る。（ユーザ定義クラスのホットデプロイはContextClassLoaderの制限があるのでできない）
設定ファイルレスでアノテーションベースでサクサク開発できる

JPAは、RDBMSを抽象化して差異を吸収する。対象はRDBMS。
JDOは、永続化を抽象化する。いままでもRDBMSに限定されていなかった (実体としては主にRDBMSを対象としていたが）。今回、DataNucleousの人たちがBigTableに対応させた。
なのでBigTableにはJDOが向いている。現状のJPAはほんとに「似せただけレベル」にちかい。いずれにせよごく一部しか使ってない。

JDOメソッドの基本（主に使うものはこんだけ）
- makePersistant(INNSERT/UPDATE)
- deletePersistant（DELETE）
- query(クエリによる検索)
- get(キーによる検索)
JDOアノテーション。こんだけですよこんだけ(主に使うのは)。
- @PersistanceCapable
- @PrimaryKey
- @Persistant
- @NotPersistant

Eclipseプラグイン使うべき。
- → 「ホワイトリスト」という機能がありGAEで使えないクラスを使うと警告してくれる。 (こんだけのためでも使う価値あり)

GAEアプリはディレクトリ構成が決まっている(src/,war/)。Mavenを使うとはまりがちなので正式サポートされるまで待った方がいいかも。でも、Googleの人はmavenが嫌いかも。antとかシンプルなのが好きかも。

 [感想] 興味の主眼であります。
今、GAEのドキュメント読みはじめたんですが、
水先案内的実用情報として役立つことこの上無し。
Slim3 for GAEについては便利なライブラリ的に
つかえそうに思った。

uehaj's blog