Hatena::Groupcatalyst

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

2008-03-05

Catalystを使ったJava風なアーキテクチャ

00:48 |  Catalystを使ったJava風なアーキテクチャ - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystを使ったJava風なアーキテクチャ - dann@catalyst  Catalystを使ったJava風なアーキテクチャ - dann@catalyst のブックマークコメント

Controller -> Service -> Domain Model -> DBIC

こういう形にすることのメリットは、

  • ServiceやDomain ModelがCatalystのフレームワークの依存から解き放たれること。
  • ControllerのロジックはServiceやDomain Modelに移り、Controllerの見にくいテストが減ること
  • ServiceやDomain ModelはPOJOならぬPOPOになるため、テスタビリティが高まること

デメリットは、

  • 疎に結合するために余分なレイヤを挟むことによるコストの増加。これはコード、テスト、DBレイヤ変更時の上位レイヤへの変更コストを含む。

こういう構成でやるときには、モデルのロジックがとても複雑な場合、モデルが多数のモデルに依存している場合なんじゃないかなって思う。

この構成でやるほど複雑な場合には、DIコンテナを使いたいなぁと。依存関係の解決はセッターインジェクションで解決されていて、ビジネスモデル側は具体的に何がインジェクションされるのかを知らない形にしたいから。具体的には、以下のような形にしたい。storageへの依存は、createのパラメータには渡さず、何に依存しているかはDIコンテナ側で事前に解決させたいなって思う。

MyApp::Model::BlogEntry->create({ 
    blog => $blog
    title => $entry_title
    content => $entry_content
});