Webフレームワークがカバーすべきこと

まず素のPHP・CGIで作ろうと思えば作れる

それで困らないら問題はない。特にPHPに至っては、クリエストリングのパースやセッションやファイルアップロードに関する関数が充実しており、フレームワークがないと困る度合いが他言語に比べると少ない。

エントリポイントの一元化

ほとんどの場合、画面全体で共通の処理が走る。例えばデータベースの接続や、必要なライブラリのrequire。特に開発環境と本番環境での設定の切り替えをここでやっとくといいエラーの画面出力を、開発環境と本番環境でON/OFFを切り替えたりとかね。

イグジットポイントの一元化

途中までは同じであっても、最後には必ず通って欲しい処理というのがある。
例えば、携帯サイトでは、機種に応じて文字コードや絵文字の変換処理が入る。さすがに最近はそこまでするケースが減ってきた。ログの出力とかはここで共通でやっておくといい。

controllerとviewの組みあわせ

「どう機能して欲しいか？」「どんな画面を見せたいか」というのが、controllerとviewの分離ということ。
これが機能するのは、こういう画面遷移。

• 　フォームに入力→送信
• 　エラーがあれば、元のフォームの画面、エラーがなければ確認画面
• 　確認画面から、更新でデータ更新、戻るボタンで元のフォーム

この画面遷移で、同じ入力フォームに「入力を受け付ける」「エラーを表示させながら再度入力を受け付ける」「確認画面から戻りながら再度入力を受け付ける」という3つのルートがある。コントローラーはそのルートを別扱いで判断をするが、ユーザから見える画面はほぼ同じものなのだ。

さらに、PCとスマートフォンの両方をカバーするようなプログラムになると、同じURLで別のHTMLを表示するようになる。この場合はcontrollerが同じでviewが違うというケース。

これがフレームワークで最も必要な機能。

処理の分岐で別画面を表示するときに、リダイレクトを使うという手もあるが、リダイレクトはGETリクエストなので、ユーザが入力したPOSTデータを引き継げない。さらにhttpヘッダの出力で画面を切り替えるために、うっかりデバッグ用の出力をすると機能しない。

モデルの抽象化

モデルという概念がある。大概の場合には,データベースに対する接続を抽象化したものである。モデルの処理は、必ずしもデータベースに実在するものでなくともよく、
　「従業員クラス」の「男女」メソッドは、DB上は、1,2という数字で入っているものを、メソッドでは「男、女」と返すみたいなことをしてもいい。
　ただ、そこまで使いこなしている人も一部で、単にデータベースの接続便利ツールとして使ってる人も多い。

「このテーブルを更新するときには、かならずこのテーブルも更新しとく」みたいなデータの整合性も、モデルが担保しておくといいが、その処理をコントローラーに書いちゃう人もいる。「必ずやってほしいこと」はモデルのクラスでカプセル化して欲しいが、このあたりは保守性の問題であって、ロジックの大きな違いにはならない。

まとめ

ということで、Webアプリケーションフレームワークでいろいろありがたいことはあるが、その価値のかなりの部分をcontrollerとviewの分離が教授しているということ。逆にcontrollerとviewが分離できないフレームワークは、結構しんどい。