煽られる前に説明しておく。
フレームワークが提供する機能が、たまたまそのまま
実践で使える場合はライブラリ使うのと変わらんが、
フレームワーク全体が密接に繋がってたりするともう駄目。
ZFとか機能切り出してるのは便利な方だが、今度は
フレームワークと言える品物かどうかの怪しくなってくるw
O/Rマッピングとか抽象化とか言うけどよ、実際にサービスが
稼働したあとでDB入れ替えるかっていうとぶっちゃけありえん。
オブジェクト試行wでねじ曲がったお陰で、本当に必要なSQLの
チューニングもできなくなるのが関の山。
ちょっとサブクエリ直せば済む話を、「設計上違う」とか言って
定期バッチで生成するどでかいキャッシュテーブル作って、
本体変えない奴ら。


　　これがフレームワーク厨やMVCモデル厨の実態。


オブジェクト指向厨なんてのもいらっしゃるが、ライブラリ
製作には便利な考え方なのでオブジェクト指向自体は悪くない。
だがOS作る訳じゃあるまいのでフレームワークはままごとと大差ない。
いわばPHPに限らずwebアプリ環境自体がフレームワークなのだよ。
データ構造と関数を整理すればいいだけという事を知ってる奴はからは
>>200みたいな観念論は絶対に出て来ない。
重要なフレームワークがあるとしたらむしろモデル云々よりテストユニットだな。