Hatena::Groupcatalyst

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

2008-03-07

CatalystでのMVCの私的まとめ

20:40 |  CatalystでのMVCの私的まとめ - dann@catalyst を含むブックマーク はてなブックマーク -  CatalystでのMVCの私的まとめ - dann@catalyst  CatalystでのMVCの私的まとめ - dann@catalyst のブックマークコメント

id:miyagawaさんやid:charsbarさんのお陰もあって、自分の中では一通り考えがまとまったので、まとめてみることにしました。

僕の場合、Catalystでテスタビリティが高いWebアプリを作るためにはどうすればよいのかとここ数週間考えていて、それを実現するにはどうすればいいのかという点に興味がありました。Catalyst::Model::Adaptor使っても、うまくいかないなぁと思っていたので、なんかいい方法ないのかなと思ってました。

特に、DBICSchemaにロジックを置くということに何か問題があるか、またテスタビリティ上問題がないのかという点がよくわからなかったので疑問点を書いたわけでした。

最終的には、http://catalyst.g.hatena.ne.jp/dann/20080305/1204732092 で書いた構成と殆ど変わらない形でも、テスタビリティは維持できそうだという結論に至りました。

Model

  • CatalystのModel」は使わない
  • テーブルのデータに固有のロジックは、DBのモデル(DBICSchema)にロジックを記述する
    • データに関連のあるオブジェクトがデータに対する責務を担う
    • 前提条件は、DBのモデルのStubが簡単に作れ、DBを介さずにユニットテストができること
  • 複数のDBのモデルにまたがるロジックは、Serviceクラス(Cというクラス)に記述する
  • Serviceクラスは、Catalystのモデルには依存させない
    • Catalystでの依存を断ち切ることで、フレームワークに依存せず、ユニットテストができるようにすること
    • フレームワークに依存していなければ、CLIなどでも簡単に使えるようにもなるということ。これはプロダクトの性質だけの問題で必要がない人もいるでしょうが、メンテナンス用の管理コマンドとして、プロダクトの場合には特にCLIのツールは必要かなという気がします。

Controller

  • Controllerにはロジックは記述させず、ServiceクラスまたはDBのモデルに処理を委譲するだけ
  • Webのコンテキストに依存する部分のみをControllerに残す
  • Controllerの主な役割は、URLマッピングとViewへのフォワードだけ

View

  • Catalyst依存
    • Viewだけの単体テストをする必要はないから

まだ、以下のエントリで書いた疑問点は完全に解決はしていませんが、大体どんな形になりそうかは想像がつきます。

http://catalyst.g.hatena.ne.jp/dann/20080307/1204847350

# miyagawaさんからのブクマコメントで、Catalyst界隈では、以下のBread BoardがDIコンテナとして注目されているとのことでした。

http://search.cpan.org/~stevan/Bread-Board-0.03/

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