PHPとMVCモデル

<愚痴>
今回の仕事で痛感したのは、単体テスト(UnitTest)を活用してないプロジェクトは全然駄目ということですね。品質に理解があるようでいて理解/実践がないし、設計、レビューを繰り返したとしても正常に動作するあるいは作成可能であるかの保障がありません。
そうなると「SIer＞下請け」ヒエラルキーの元で、割を食ってしまうのは下請けのプログラマです。単体試験の工費を貰えず、単体試験を省けば、不具合/障害の責任はプログラマにある。また、単体試験を行えばスケジュールに合わない。余計なことをやっているとみられる。時間を削られれば学習の時間（次への投資）ができなくなる。じり貧になってしまうのは、下請けの底辺プログラマばかり。
というわけで、今後そういう仕事は請けないことにします。
</愚痴>

な訳で、インストールマニアックスでPHPを少し触ったことだし、ASP.NETの開発者よりもPHPの開発者が多いわけだし、あるいはJava開発者が多いし、ということで、PHPとMVCあるいはMVVMの組み合わせはどうかな？とざっと調べてみました。

目的は、

・PHPの開発者が理解できる標準的なMVCモデル
・PHPの軽さ/手軽さを活かした開発スタイル
・基本はLAMP（Linux+Apache+MySQL+PHP)
・単体テスト/PHPUnitは必須
・自社開発の効率化/品質Up
・できれば、巷のオープンソースに組み込みやすい/流用しやすい

なところです。

PHPと他各種言語の比較記事
http://phpspot.org/blog/archives/2007/01/php_69.html
PHPUnit3で始めるユニットテスト
http://gihyo.jp/dev/feature/01/php-test/0001?page=1

PHPフレームワーク　ちいたん
http://php.cheetan.net/
軽量なMVCフレームワークの自作（改訂版）
http://codezine.jp/article/detail/104

CakePHP
http://cakephp.jp/
CakePHP プログラマーズ リファレンスガイド
http://cakephp.jp/doc/

ざっと調べてみると、フレームワークとしてはCakePHPの評判が良さそうです。ただし、Ruby on Railsの影響を強く受けているみたいなので、Railsを知らない人/好きでない人にとっては、メリットが薄れます。ちなみに私は「Railsを知らない人」です。

現在、PHPを使ってWEBアプリを作るメリットとして、

・PHPの開発者は比較的多い（文法が簡単だから？）。
・LAMPのひとつとして確立されている（メジャー度）。
・レンタルサーバーではPHP、Perlが入っているところがほとんど。

なわけで、安いサーバーを使って、広く技術者を求めることが可能、かつ顧客にも説明しやすいというメリットがあります。

デメリットとしては、

・負荷の話になると、Java/.NETが有利
・データベース接続がMySQLが基本？（既存のOracleに接続するとか）
・クラスが一般に認知されていない？（PHPのクラス解説ブログ/ページは少ない？）
　よって、開発者が減る。
・Visaul StudioやEclipsのような開発環境が無い？（インテリセンスとかコンパイル時エラーとか）

なところでしょうか。
あと、うがった話で言えば「PHP開発者が大勢いるといることは、Javaや.NET、C++ほど優秀な人が少ない？」という偏見も出てきます。これはよくわかりません。モデルの会話とか、フレームワークの会話を実際にしたことがないので。なんかいい勉強会とかありませんかね？

# ちなみに Java の人と会話すると、直ぐにインターフェースとリスナーを駆使したクラス至上主義なモデルになってしまい困りものです。.net だとデリゲートがあるし、Rubyはメソッドを追加することができるし、と言語特有の特徴/有意性があるので、JavaライクなC#コードを書かれても、困るんですが。

さて、ASP.NETにもMVCフレームワークというのがリリースされていますが、何もその実装フレームワークを使わないとMVCモデルが実現できあい訳ではありません。先のエントリにも書きましたが「モデル」≠「実装」という実現の仕方でもよいのです。
特にMVCモデル（Model-Viewパターン）はViewを分離させようという発想、自動化できるUnitTestを使おうという発想が先にあるので、ここをきちんと押さえないと、ただ何かのフレームワークを使っている（お仕着せのライブラリとか）になってしまいます。

MVCフレームワークが気持ち悪くなってきた
http://d.hatena.ne.jp/ghostbass/20081126/1227673389

そういう点で私は上のエントリに同意します。

おそらくJavaのStrutsの影響を受けると、本来のMVCモデルが失われてしまうのかな？と。

少しPHP-MVCモデルと離れますが、思いつきを書いておきます。

PHPの大きな特徴は大抵のレンタルサーバーで使えることです。ですから、WEBサイトの数々の管理ツールをPHPで書いておくことは大きなメリットです。たとえ、サイト自体がJavaやASP.NETで運用されていたとしても、マスター管理の画面など管理者が使う画面をPHPで書いておけば、作成や改修にそれほど時間/工数をかけずに済みます。PHPのインストールは必要でしょうが、特定のPEARに依存せずインストールが楽になれば、別の言語であっても構わないのです。顧客向けのページをJavaやASP.NETで作成し（お金をかけ）、少数の管理レベルであればコマンドライン制御も含めて、PHPで手軽に書く（お金をかけず）、という適材適所の思想が必要です。そう、建築と同じで、どこでも檜を使えばいいってもんじゃないでしょう？

このとき、マスター管理などの画面を作るのに導入コストがかかるフレームワークは避けたほうがいいでしょう。勿論、同じ言語で同じ技術者で作りたい気持ちも分からないのではないですが、それだけ無駄なコストが掛かります。オーバースペックなわけです。

となれば、手早く作る部分には下記の要件が必要です。

・軽量なPHPのフレームワークであること。
・頑健であること。
・導入/学習コストが低いこと。
・不足を補う方法が用意されていること。

先の２つは軽量/頑健さを求め、複雑を排除します。単純であれば学習コストも減るでしょう。拡張性をトレードオフしますが、一定の複雑さを求めるのであれば、別のフレームワークを使うか、javaなりasp.netなりを使えばよいのです。

不足を補う部分を具体的に話せば、巷のオープンソースはPHPのコードをPHPから出力する自己記述を行いうまい具合に閉じていますが（これはこれでいいのですが）、何もかもこれでやるのは無理があります。
なので、設定自体をExcelで書くとか、コードの自動生成をExcelから行う（あるいはJavaのコマンドを使う）などの組み合わせがあってもいいはずです。
# 逆に何もかもExcelというのも無理があります。

こういう観点からPHPにMVCモデルを組み合わせると、いくつかの案がでてきます。
おそらく「ちいたん」がそれに近いと思います。

・VB6.0でCOMを扱うような手軽さ。
・VB6.0でCOMを扱うような頑健さ。
・中身が容易に想像できること。
・設定が一か所にまとまっていること。
・テストツールが用意されていること。

VB6.0とCOMの繋がりは非常に疎ではありますが、疎結合ゆえにメソッド/プロパティが用意に想像できる単純さを持っています（中身は複雑ですが）。
この外見の容易さは、車のハンドルを左に回すと、車が左に曲がるというアクションと動きの一致の重要さに通じます。見えない構造はどれだけ複雑でも構いませんが（実際CPUの回線は複雑だし）、活用する場面においてその複雑さを表に出してはいけません。
なので、MVCモデルを導入する際も、「中身が容易に想像でき」、インターフェースを眺めることができるように「設定を一か所にまとめる」工夫が必要です。あちこちのファイルを修正しないといけない実装は、ケアレスミスを誘発しますし、学習コストを押し上げてしまいます。

そして、忘れていけないのが、設定がきちんとできているか、その実装は思った通り動いているのかをテストするツールが必要なのです。最近、SQL Serverでは設定のチェックを行うようになりましたが、ほとんどのフレームワークは自己テストを行いません。
私がいささかスクリプト言語を敬遠するのは、コンパイル言語であればコンパイルすれば取れるエラーが、スクリプト言語の場合実行時にしか取れないことが多いためです。
# perlには文法チェック -wc というオプションがあります。ruby の場合は -c かな。

これだけ頑健にしておき、実装時のエラーが取れていれば、あとは開発者が作った独自のコードのエラーを取るだけです。UnitTest のフレームワークを活用しておけば（これが必須なのですが）、その延長線上でテストを作ることもできるでしょうし、本来 Model の UnitTest が実践できるという、MVCモデルの発端の思想に沿うものができます。

というわけで、無事 PHPとMVCモデルに戻ってきたわけですが、このあたり、実装できているMVCフレームワークは欲しいですか？