何を今更…と言う様な話なのは重々承知ですw
PHP4もライフサイクルが終了しますので、来年を持って会社で開発・使用していたFrameworkも終了し、ZendFrameworkに乗り換え様かと会社のSEさんが言ってました.
そうだよね.
と言いますか、ぶっちゃけ乗り換えがかなりの勢いで遅いですw
しかしそれもPHP4で運用している環境をサポートしなければならなかったが故(ZendFrameworkはPHP5.1.4以降で動作).
致し方なしと言った所でしょう.
所で、lightmaterialを含め会社の人はPHP/.Netを使っているんですが、.Netの影響か会社のPHPFrameworkではDBに対するINSERT/UPDATE/DELETEをマネージャで実装しています.
勿論正確にはDBAdapter(DataBase用のアダプタ)のメソッドを呼び出すのがマネージャな訳です.
ADO.Netも似た様な構造です.
fillしたデータの各行に対して変更を加え、それらDBへのコミットはDataAdapterから行いますが、それを呼び出すのは当然マネージャなりデータを操作するクラスだったりします(個別に操作する別の方法もありますが、オブジェクト指向としては醜い方法です…と思いますw).
が、ZendFrameworkのマニュアルを読むとDataRowクラスに「save」メソッド(追加・更新をDBへ反映させるメソッド)が実装されています.
要するに
$objRow = $objTable->createRow();
$objRow->save();
//-> 酒飲みながら流し見してたので本当にTableからcreateRowするかは確認してませんが、普通に考えればTableクラスから生成するかと.
な訳ですよ.
…いや、確かにそう言う実装方法も色々と見て来ましたので、別に戸惑う事でも何でもないんですが、ふと「あれ?DBへの追加・更新用のメソッドって、どこに実装すべきなんだ?どこに実装するのがエクセレントなんだ?」と言う疑問が湧き上がって訳です.
実際の所、どちらの方がスマートなんだろう?
各Rowに対する変更をTableオブジェクトでストアして一気にコミット…大量のデータが変更される環境では、トラフィック効率が非常に魅力的な方法です(リアルタイム性に欠けるんですがw).
一方、各Rowにsave/deleteメソッドが実装されていると、小回りが効くと言うか、何かしらのインポート処理では無い限り、こちらの方がリアルタイム性+トラフィック効率が良い様な気もします(さっきと書いてる事違うじゃない…と言う事は無く、一度に大量の処理が発生する場合は前者の方がトラフィックが減りますが、1レコードしか更新しない場合には後者のほうがトラフィックは少なくなります).
ただしこの方法、数万レコードのインポート処理が発生するプログラムの場合、相当処理が遅いんじゃないの? orz
うーん.
難しい.
Javaのデータベース周りって、どっちの方法がスタンダードなんだろ?
どちらのアプローチも間違いじゃないから悩ましい.
でもZendFrameworkに乗り換えるのは殆ど決定事項みたいですので、これからは2つのアプローチに慣れる必要がありそうです.
それにしても、会社のFrameworkってプログラム量が凄い少なくて済む(と言うか、かなりの勢いで全自動)から気に入ってたんですけどねぇ.
ちょっと残念です.
2007年9月28日金曜日
登録:
コメントの投稿 (Atom)
0 件のコメント:
コメントを投稿