質問: PHPでフレームワークを使って開発しています。 ウェブなどで「ECサイトのショッピングカート」の作り方の解説を見ていると、 * ショッピングカード→Cartクラス * 商品→Itemクラス ↑のようになっているものがありました。 これをMVCフレームワークで実装する場合はこれらのクラスもMVCのどれかに所属するのでしょうか? CartクラスやItemクラスはプログラムのパーツになっているので特定の機能に属するとは考えにくいです。共通する処理はサービスとしてまとめると見通しが良くなると習いましたので最近はMVC+Serviceという形にしていますが、パーツも更に追加してMVC+S+Partsみたいな形になるのでしょうか? 自由にファイルは追加していけるので、どういう構造になろうとフレームワークを使う側の勝手ではありますが、フレームワーク元々のMVCという形から離れてしまって問題は起こらないのでしょうか? 質問させていただきたいのは下記2点です 1. MVCフレームワークに独自の構造(今回の例ではサービスとパーツ)を追加していってフレームワークの動作に何か影響はないのか? 2. MVCにおいて今回の例のCartクラスやItemクラスはどこに位置付けられるものなのか? よろしくお願い致します。
回答: > > フレームワーク元々の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の書籍でも原理論を端折りがちで、 「なぜそうするのか」が分かりにくいですが、だからこそ意識的に探す必要があります。