データ隠蔽の実装方法について
■ このスレッドは過去ログ倉庫に格納されています
0001なんちゃってプログラマ
NGNGActiveX DLL(コードコンポーネント)を作成し、DBの操作部分を
全アプリで共通化したいと思うのですが、DBからレコードを取得
する方法で意見が２手に分かれてしまいました。
1.アプリへレコードセットは返さず、すべてのDB操作をアプリ側
から隠蔽する。
2.DBから取得したレコードセット(読取専用)を直接、アプリ側へ
返す。
データ隠蔽と言う意味で1.の方が仕様として綺麗なのは分かるの
ですがMoveNextのようなレコード移動系のメソッドまでDLL側で
ラッピングしなければならずそれが、逆に安定さを欠くのではないか
という意見があります。
2.は、単にSQL文とストアドの呼び出し部分が隠蔽されているだけな
のですが、ADOでの開発経験がある人たちは、直にレコードセットを
扱えたほうが、開発効率が良いと言います。
みなさんの意見をお聞かせ下さい。
0002>1
NGNG0003俺個人的には
NGNGでも1の意見もわからんでもない、でもやっぱ2番の方が良いよ。
意味不明かな？
0004名無しさん
NGNG0005優秀な人ばかりなら
NGNGかな。
0006名無しさん
NGNG#ADOにはDAOと違ってダイナセットが無いなら別。
１の方法だと、一々ＤＬＬを経由しないと各データフィールドを参照出来なくなるので、オーバーヘッドが大きくなる。
だから、俺なら２。
0007にわかADOプログラマ
NGNGADOにもダイナセットはあったはず。
私も５と同じ方法取るかなぁ、時間さえたっぷり取れれば。
0008６＞７
NGNGそれと、無理にＤＬＬにしないでも共有ライブラリの世代管理をきっちりやれば、それでＯＫなんでない？って気がするんだけど？＞１
0009>8
NGNGって書いてあるから、アプリへはスナップショットしか渡さないんで
ないの？ダイナセット渡しといて、データ隠蔽なんてありえないよね。
インプロセスCOM相手にオーバーヘッド云々言ってたらVBで開発なんて
できないのでは？
0010名無しさん
NGNGカレントレコードの各フィールドへの参照する処理の実装コストとオーバーヘッドを考えれば、半端な隠蔽などしない方がましだと思うのだけど。
アプリ内でのデータベース参照手段の共有が目的なら、フィールドから「構造体」へのコピーが全フィールドを参照する訳でもないのに毎回発生するのを覚悟の上でやるのも一つの選択かも知れない。
でも、その分間違い無く遅くなるし、ライブラリの消費者に対して悪い意味でのスポイルになっちゃう事も考えに入れて置かないと。
001110
NGNG0012五分刈少年
NGNGいいんじゃないの？
オーバーヘッドはミリ秒〜１０数ミリ秒オーダーだと思うし。
■ このスレッドは過去ログ倉庫に格納されています