「PHPでMVC」するための第一歩

  • 投稿日:
  • by
  • カテゴリ:
  • タグ:

昨夜、少し勉強してみたのですが、MVCモデルっていいことばかりでもないような?

まず第一に、ファイル数が飛躍的に増えます。

現在の「プランB」は、原則として「1ページ=1ファイル」です。 Smartyを使っていますが、テンプレートは10個程度です。 ページの種類によって分けているのは3個だけです。
他にAjax関係で呼び出すphpファイルもありますけど、それも10個ない程度です。
D/Bとの接続やPEAR::Auth認証は別ファイルにして、require_once しています。

MVCモデルにすると極端な話、1ページがモデル、ビュー、コントローラーの3つのファイルに分かれます。 モデルは複数ページで共用できるでしょうが、それでも2倍以上になります。
1つのページを作るのに、複数のファイルを開いて作業しなければならないのは、ちょっと煩雑な感じがします。
デザイナーとプログラマーで作業を分担しやすいのはメリットでしょうが、現状では一人で開発しているので...

コーディングの量も増えそうです。
今のところ Javascript を除いたPHPコードだけで、1ページあたり600行(80桁換算)くらいです。
簡単なページの場合は、むしろMVCモデルにすると書く量が多くなってしまうようです。

見通しが悪くなるんじゃないかという危惧もあります。
手続き型のよいところは、「順に眺めていけば何の処理をしているか分かりやすい」点です。 出来上がりのHTMLをイメージしやすいですね。
複数ファイルに分かれて「しまう」ことも含めて、スキルがある人でなければ理解しにくいものになりそうです。

最後に、テーブルの INNER JOIN との関連について。
D/Bとやりとりする部分をモデル(M)にしてしまうというのは分かりましたが、現在の「プランB」はテーブルが61個あります。 これらのテーブルについて、いろんな組み合わせで INNER JOIN したクエリを発行しています。
モデルとテーブルが1対1なら分かりやすいのですが、 INNER JOIN の組み合わせごとにモデルを作らなければならないのであれば、ちょっと面倒ですね。


なんてブツクサ書きましたが、それでもMVCモデルに興味を持っているのは、現在の各ページに似て非なるコードが遍在しているのが気になっているからです。

function や class 化すればいいのでしょうが、書いているときはそれが汎用的な処理か判断しづらいです。
「えーっと、この処理はなんかのページで前にやったなぁ。 どこだっけ?」なんてこともあります。
だから、そろそろ書き方を改めたいと思っているのです。


という訳でまだまだ勉強中です。 以下、備忘録。

「てくめも@coop」さんの記事は分かりやすくて参考になりました。 「PHPでOOP」さんのMVCフレームワークのページも、概念を理解するのに役立ちそうです。
「Moonmile Solutions Blog」さんの記事も興味深いです。
ありがとうございます。