おはようございます。雨の日は髪がヘナッとなって気分が悪いbGです。 今の会社に入ってまだ1ヵ月ぐらいなんですが、一緒のチームの人が寛大なので開発方法におれのわがままを取り入れまくってもらって軽くアツイです。
わがままというのはPHPほぼ素人のおれが、「MVC意識したフレームワークを作ってそれでやりませんか」みたいなことを言ったわけです。 一回ベタでやり始めるとヘボイなりの”資産”（関数満載のincludeファイルとか）ができちゃってそれを手放さなくなって寒い方向に行きそうだったので無茶承知で言いました。 そんな暴言を許してくれるんだからその人はズバ抜けて寛大と言えましょう。
フレームというぐらいなのでまず単に枠（ファイルの配置とかの取り決め）を作ります。 そのあと以下のようなWebアプリに必要な処理を用意していきます。
・エラーの処理 ・ログの処理 ・Requestの処理 ・Templateの処理 ・Databaseの処理
PHPの場合はTemplateはSmarty、DatabaseはPEAR::DBなんぞを使うので本当に枠だけって感じになります。
一番悩むのは”DBとの繋ぎ目をどうするか”です。 コレ、普通にやってるといきなり感じると思うんですが、 「データベースって何だよ！全然OOPじゃねーじゃん！」 とか思ってしまいます。感覚的に全然違うじゃん！と思って調べてみるとそもそも
プログラム ：OOP(Object Oriented Programing) データベース ： DAO
で全然考え方が違うっ！ 単純に例を考えると、一つの商品に対応するItemsクラスを作るとする。DBにはItemsテーブルがあるとして、ItemsクラスはItemsテーブルのカラムに対応するプロパティを持っている。 ここで1000個のItemsオブジェクトを生成するとデータベースにSQLを1000回投げることになる。そんなもんベタ書きで一回のSQLで1000個持ってくりゃいいじゃねーかって話になる。
問題はそんな単純なことじゃないかもしれないけど要するにかなり厄介らしい。PHPでもそのへんをうまくやってくれる（予定）のDB_DataObjectというのがあるがまだこなれてないらしい。PerlのClass::DBIは結構使われてるのに。 「SQLがムカつくんですよ」 と会社の人に言ったら単にSQLがわかんなくて苦労していると思われた。この辺をいきなり導入するのはちょっと無謀か・・・。UML一辺倒の風潮に警鐘、日揮情報
そもそも、DOAの手法は、データ分析、リレーショナル・データベースの設計から実装、メンテナンスまで一貫したモデル駆動型開発として業務系システムを構築する際に活用されており、現在でも多くの開発者がこの手法を採用している。一方、オブジェクト指向言語を使うOOPは、プログラムの部品化や再利用を想定し、データとその振る舞いをカプセル化してしまう。このため、データを独立させるDOAとOOPを融合させることは不可能ではないものの、煩雑な手続きを必要とした。同社ではUML一辺倒の風潮に警鐘を鳴らす意味も込めて、「オブジェクト（O）-リレーショナル（R）マッピング」技術を実現する製品を投入し、自社で開発したアドオン製品を加えて、1つのソリューションとすることで、ソフトウェア開発の方法に新しい道を示そうとしている。