とりあえず雑記帳(跡地)
Daoが現れたよ
最終更新:
fujiyan
-
view
Daoの出現
- [gen-model-with-dao]targetでModelを作成すると、[Root Package]直下に"dao"というサブパッケージが作成され、その中に[作成したModel名]Daoというクラスが自動生成されます。
- BookDaoの場合
package jp.fujiyan.booklist.dao;
import org.slim3.datastore.DaoBase;
import jp.fujiyan.booklist.model.Book;
public class BookDao extends DaoBase<Book>{
}
- 一見すると、何にもなさそうですが、スーパークラスであるDaoBaseに、Datastoreでの操作に必要なメソッドが一通り定義されています。
メソッド | 内容 |
put | 引数に指定したModelを永続化します |
delete | 引数に指定したKeyのModelをDatastoreから削除します |
get | 引数に指定したKeyのModelをDatastoreから取得します |
query | Datastoreに対する、Modelの問い合わせを実行するための、ModelQueryを返します |
Daoとはなんぞや
- Daoは、とあるModelについて、Datastoreに対する操作を管理するクラスになります。
- Datastoreを操作するためのクラス(com.google.appengine.api.datastoreや、org.slim3.datastoreに属するクラス)は、「極力」Daoパッケージのクラスを通じてアクセスするようにします。
- その他のパッケージ(後述のServiceやController等)は、Datastoreを操作するためのクラスとの依存関係を持たないようにします。
- もちろん、いくつかの例外もあります。
- Entityの物理キーであるKeyクラス。Keyオブジェクトを利用して、操作するModel(Entity)を指定するためです。
- なぜ、そうするのかというと、将来、Datastoreを操作するためのクラスのアーキテクチャが変更/拡張された場合に、その影響をDaoパッケージのクラスのみに押さえ込むためです。
パッケージ図
- 上記の場合、Serviceパッケージは、常にDaoパッケージを通じてのみ、Datastoreにアクセスするようになります。
- これによって、Datastoreのアーキテクチャ変更について、Serviceクラスは気にしなくても良くなります。
- このように、クラスをパッケージ単位で分割し、パッケージ間の依存関係を極力単純(依存するパッケージ数を少なくし、その依存関係も単方向)にすることで、変更に強いアプリケーションとなります。
Daoのカスタマイズ
- DaoBaseで定義された、標準的な操作ではプリミティブ過ぎて扱いづらいので、実際にはよりModelを扱いやすくするためのメソッドを適宜定義していきます。
- そのメソッドの中で、DaoBaseのメソッドを利用していくことになります。
- まぁ、その辺は後ほど
添付ファイル