MVCフレームワークでその他のクラスはどこに入るのか？

Question

PHPでフレームワークを使って開発しています。

ウェブなどで「ECサイトのショッピングカート」の作り方の解説を見ていると、

• ショッピングカード→Cartクラス
• 商品→Itemクラス

↑のようになっているものがありました。
これをMVCフレームワークで実装する場合はこれらのクラスもMVCのどれかに所属するのでしょうか？

CartクラスやItemクラスはプログラムのパーツになっているので特定の機能に属するとは考えにくいです。共通する処理はサービスとしてまとめると見通しが良くなると習いましたので最近はMVC＋Serviceという形にしていますが、パーツも更に追加してMVC+S+Partsみたいな形になるのでしょうか？

自由にファイルは追加していけるので、どういう構造になろうとフレームワークを使う側の勝手ではありますが、フレームワーク元々のMVCという形から離れてしまって問題は起こらないのでしょうか？

質問させていただきたいのは下記2点です

1. MVCフレームワークに独自の構造（今回の例ではサービスとパーツ）を追加していってフレームワークの動作に何か影響はないのか？
2. MVCにおいて今回の例のCartクラスやItemクラスはどこに位置付けられるものなのか？

よろしくお願い致します。

Comments

[ozwk]

MVCのMを何だと認識してますか?

[msx2]

MはModelでビジネスロジックが入るところだと思います。
何となくデータのやり取りをするクラスというイメージですが、もしかしてショッピングカートクラスもModelに入れてしまうといいのでしょうか？

Answer 1

フレームワーク元々のMVCという形から離れてしまって問題は起こらないのでしょうか？

そもそも、なぜMVCなのでしょうか。何がしたくてMVCにするのでしょうか。

まず、MVCにすると、分業ができます。M側にPHPやSQLなど、V側にHTMLやJSと、
今では当たり前の分業制も、Webアプリ以前のPCアプリはそうではありませんでした。

では、ひとりで書き分業しないなら不要かといえば、保守性もあります。
UI部分は変更されやすいので、そこを分離してあると保守しやすいです。

だから、MVCを崩すと、分業容易性、保守性などが低下する問題があります。

---

MVCにおいて今回の例のCartクラスやItemクラスはどこに位置付けられるものなのか？

結論から言うとMです。

そもそもM＝モデルの中心は、ドメインモデルです。ではドメインとは何でしょうか。
ショッピングサイトなら、ショッピングです。販売に関する機能です。

「カート」や「商品」は販売の仕組みですから、ドメインモデルであり、Mです。
もちろん、それを表示したり操作する部分はVとCになります。

これはたとえば、自動販売機の中のジュースとその容器がMで、
見本の缶とボタンなど、外側をVCと思えば理解しやすいでしょう。

---

PHPを使うユーザの多くは実用第一なので、PHPの書籍でも原理論を端折りがちで、
「なぜそうするのか」が分かりにくいですが、だからこそ意識的に探す必要があります。

Comments

[msx2]

ご回答ありがとうございます。
Model＝データベース（テーブル）という固定概念がありましたがそうではないのですね。「MVC」と「ドメインモデル」で検索するといろいろと情報が出てきました、勉強になります。

Answer 2

UIに直接関係ないものは全部Mです。
MVCはUI周りのアーキテクチャであって、
UIじゃない部分:Mをどう作るかは関心事ではないです。

雑な例で行くと
UIはMVCでレイヤー分けして、
モデルはドメイン層とユースケース層に分けようみたいな感じです。

Comments

[msx2]

ご回答ありがとうございます！
UIに直接関係ないものは全部Mでいいんですね。納得です。

>モデルはドメイン層とユースケース層に分けようみたいな感じです。

最後のこの1行は私の知識では見えてこないのですが、何でもかんでもModelに詰め込んでしまうと1つ1つのModelが大きくなってしまうので、Mの中で適切な分け方がありそのキーワードが「ドメイン」と「ユースケース」だと理解しています。

新しいキーワードを教えてもらったので自分でも調べてみたいと思います。