somemo's diary

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

【パターン】MVCパターンのM

MVCのおさらい(Web)

M:Model。データ処理部分担当。

V:VIEW。画面表示部分担当

C:Controller。画面からのリクエストをモデルに受け渡す役割

 

Controllerではデータ処理を行わない。 MVCのざっくりした説明はこれでいいと思います。

しかし、最近の?フレームワークだと 「Modelファイル=テーブルレコード」という扱いになっているので、 複数のテーブルにまたがる処理をどのModel担当にするか迷います。

そもそもMVCだけじゃ足りないということに気づきました。 Mの役割としては、個々のテーブルレコードに対する処理を書けばいいことに変わりはありません。

Cから複数のテーブルにまたがる処理に対応する担当を増やせばいいのでは?ということに気づきました。 上記の担当から、Mに対する処理を個々に呼び出して実行すればいいということです。 (データ不整合がおきそうな場所をトランザクション張ってまとめて処理するイメージ)

PHPフレームワークの場合、 CakeやZendではModuleという概念が無いので、対応する担当を作らないといけないですが、 synfonyであれば、moduleのlibに作ればいいのかなと思います。

DDDやPofEEが役に立ちそうです。 ただ、厚い本なのでまだ手がつけられそうに無いです。

 

参考リンいろいろ

Ruby on Railsの「えせMVC」の弊害

O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」

Webアプリケーション内のMVCアーキテクチャ

えせMVCについてそろそろ一言言っておくか

RailsはModel View Controller じゃなくてModel View Service Controllerにすればいいんじゃね?

PofEAAのWiki Web アプリの MVC 設計まとめ

えせMVC?

MVCにこだわるのは無意味 MVCのMんところ MVC、これでいいのか?

Domain-Driven Designのエッセンス(オブジェクト広場) MVACってなぁに?

MVC、お前もか

MVC云々の話・コードの量の問題じゃないかな