Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-03-07

Serviceクラス(Cというクラス)のCatalystのModelからの依存を断ち切るには?

08:49 |  Serviceクラス(Cというクラス)のCatalystのModelからの依存を断ち切るには? - dann@catalyst を含むブックマーク はてなブックマーク -  Serviceクラス(Cというクラス)のCatalystのModelからの依存を断ち切るには? - dann@catalyst  Serviceクラス(Cというクラス)のCatalystのModelからの依存を断ち切るには? - dann@catalyst のブックマークコメント

SpringなどのDIコンテナでは、DAOがどのDBを見に行くかとかというのは、DIコンテナがDAOを生成するときに設定する。それは、Webなどのコンテキストには依存していないし、Webのフレームワークには依存していない。

今は、CatalystのConfigLoaderでmyapp.ymlを読み込んで、Modelはその情報を参照している。要するに、CatalystがDIコンテナの一部の役割を担っているということになる。Webのコンテキストという意味では依存していないのだけれど、Catalystには依存している。

ここを切り離さないと、Cというクラス(自分はServiceと呼んでいる)の、Catalystへの依存というのが切れない。依存を切り離す一つの解は、Catalyst::Model::Adaptorを使うことなのだけれど、Configurationを参照させる部分、または、DIコンテナを作るというほうが自然なのかもしれないと思った。

仮にCatalyst::Model::Adaptorを使って、Serviceに処理を委譲する形にしても、Serviceのバックエンドで動作するDBICSchemaは、どのDBにConfigLoaderを見にいくのかというのを知りたいわけだし、そうするとCatalystからの依存はCatalyst::Model::Adaptorを使っただけでは依存が切れないような気がした。

これはどう解決するのが綺麗なんだろうなぁと思っていたのだけれど、miyagawaさんのエントリを読んでから考え直した。

ControllerでのURLマッピング、Viewへのフォワード部分だけを、Catalystの機能として使って、後の部分はPOPO(Plain Old Perl Object)として扱って、DIコンテナで間を繋ぐという形が綺麗なのかもしれない。DIコンテナで繋がなくても、ConfigurationのデータをPOPOが参照できる仕組みがあれば、「Catalystに依存したCatalystのModel」の部分はなくすことができる気がする。

CatalystのModelでyaml参照させるためだけに、Catalystに依存してしまうということ自体が間違いかもしれないということが分かったのは、大きな収穫な気がするなぁ。

大分すっきりしてきた気はするので、あともう少し詰めれば、Catalystを使って、テスタビリティの高いアプリケーションも作れるような気がするなぁ。別の解もある気がするから、もう少し考えよう。

トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080307