somemo's diary

プログラマ、雑記、プログラミング関係はLinkから、数式はこっちでまとめていることが多い

【パターン】データソースア-キテクチャ

Zendframeworkの勉強中に、がっつり調べてしまったのでメモです。

データソースア-キテクチャ

データソースにアクセスするときに関するアーキテクチャです。主に永続的なデータとしてデータベースにアクセスすることをよくまとめてあります。

パターンとしては4つあるようです。

TableDataGateway

テーブルにアクセスするためのパターンで、テーブルとクラスが1対1対応しています。経験したところだと、PropelのPeerのはず。ZendのZend_Db_Table_Abstractも同じかな?

テーブルからレコード検索する際によく使ってました。単一レコードを検索する際には、集まりではなく、レコードのみを返すこともあります。集まりは、ZendのZend_Db_Table_Rowset_Abstractと同じで、単一レコード用のイテレータになりうるかも。

RowDataGateway

レコードにアクセスするためのパターンで、レコードとクラスが1対1対応しています。経験したところだと、Propelのmodelのはず。ZendのZend_Db_Table_Row_Abstractも同じかな?

レコードの登録、更新、削除といったCRUDのR抜き動作をメインに行っていました。

ActiveRecord

RowDataGatewayが、ドメインロジック(業務用のロジック)持っているパターンです。cakePHP、Doctrineでよく使っています。

DataMapper

業務上のモデルに対応するテーブルへのアクセスを専門に担当しています。

RowDataGatewayやActiveRecordと違って、モデルがMapperのことをまったく知らないような作りになっています。Mapperは、モデルを使用してテーブルへのアクセスを行います。

JavaServlet入門などでよく見かけていると思います。ZendもMaaperがいいとか?

今までを振り返ってみて

モデルに携わったのはsymfony1.0を障ったときが初めてでした。そのときは、PeerとPeerなしのモデルに出会い、何で分かれているんだろうと思っていました。それ以前に、コントローラにCriteria直書きでした・・・

ある程度経験してからは、Peer無しに登録・更新・削除などの1レコードに対する処理があり、Peerありはテーブルレコードを直接扱うメソッドが継承されていることから区別化ができました。

ただし、テーブルをまたがった処理をどこに書けばいいのかという疑問が浮かびました。

また、ドメインロジックをどこにおくのか?そもそもドメインロジックという分類を知らなかったので、コントローラのprivateメソッドに書いたり、各モジュールを大分類の機能の分散として扱っていたので、その機能のユーティリティとして書いていました。このころから、モデルのあり方に悩み始めます・・・

さらに追い討ちをかけたのが、cakePHP、Doctrineといった詰め込みのActiveRecordです。簡単なアプリであれば、まとまっていてよいのですが、複雑になると責任わけができていなぁと思っていました。

これから

システムや、フレームワークの思想を組んであっていないものは別のものに取り替えたり、修正したりなどしてがんばろうと思います。

あとは、積み本になっているPofEEA、アナリシス、DDDを読もう。