技術・独学の人友の会コミュのADO.NET のデザインを考えてみる。

.NET テクノロジが世に送り出されてそれなりの月日が過ぎました。

やはり，ASP.NET の開発生産性のよさはかなりのものだと思います。
世の中にも aspx なページも結構見るようになってきましたし。

自分は Web の開発はあまりやらないんですが，
CLR の共通機能で書いておくと，
VB.NET ←→ Ｃ＃の移植が楽で楽でしょうがない。
（まぁ，限界はありますけど，十分満足いけるレベルだと。。。）

本業のＤＢ周りの操作にしても，
やっとこ ADO.NET の操作もひととおりこなしたか？
といったところ。
ADO からのパラダイムシフトに対応して，
文字で突きつけられる仕様を，なんとか実装できる程度にはなれたわけです。

。。。が，しかし！
その Dataset の使い方はパフォーマンス最適か？
その更新手順の実装の仕方は，迂回手段じゃないのか？

アーキテクチャの選択が最適なデザインになっているのか，という疑問が押し寄せてくるのです。

「とりあえず，動く」
ただ，それだけのモノを書いてしまっているんじゃないのか？
そんな不安ですね。

何通りかのアーキテクチャデザインが可能な場合は，
できる限りそれぞれを実装して試してみるんですが。。。実際にはそんなに時間もない。

こういった更新シナリオには，アダプター経由で更新を管理。
この表示コントローラーには View を介して。

と，
シナリオ←→デザインと対応した，定石。
というものがほしくなっているわけです。

こんな症状に効く，いい薬ないですか？

コメント(4)

最初
全て
最新の40件

[1] mixiユーザー 11月01日 23:40

えーっとアーキテクチャ選択という点ではPoEAAにTableModuleというものがあるので、それがいい薬になりそうです。

でもきっとなんでもデータアダプタというのも、やめておいたほうがいいと思います。DBから1行とってくるのにデータアダプタは確か重過ぎると思うので。

Datasetに関してはドットネットマガジン12月号(最新号)の尾島氏の記事がトーっても参考になりそうですよ。
後ADOで非接続型レコードセットを多用していた身としては、ADO.NETにはあんまり違和感がありません。

VB.NETとC#の移植に関しては、その必要性はともかくオライリから出ている「C#&VB.NET比較ガイド(ISBN4-87311-107-2)」は持っておいたほうが良い本だと思います。

[2] mixiユーザー 11月02日 00:40

ほぅほぅほぅ。
TableModuleですか。ありがとうございます。

そうなんですよね。
自分も ADO の非接続と，バッチ更新を多用していた身なので，
目標とする考え方自身には違和感がないんですけど，

それが故に，今までのデザインをそのまま使おうとしてしまって，
それが実装レベルでパフォーマンス最適なのか，自信がない。
といった感じですね。

[3] mixiユーザー 11月02日 08:45

最適なアーキテクチャの選択かぁ。
悩ましいところですよね。

たとえばなんですけど、WindowsアプリのDataGridとASP.NETのDataGrid、見た目や使い方だけじゃなくて、設定できるDataSourceも違ってるんですよね。
ASP.NETではDataReaderもDataGridのDataSourceとして設定できます。
となると、ASP.NETではDataAdapterとDataSetを使わなくてもアプリケーションを組めるわけで。
で、重いDataSetを使うのはどうだろう、という話がでてきたりします。

実装レベルで考えると、FCL（Framework Class Libraly）が何をサポートしてくれてるかまで考える必要がでてきますものねぇ。

[4] mixiユーザー 11月02日 09:33

一晩いろいろ眺めてみましたが。。。
やはり，
こうできる，こんな実装もある。
っていう情報は結構あるものの。

やはり，このデザインの実装にはこれ。
っていう情報はなかなかないですねぇ。
ＭＳプレスの ADO.NET プログラミングの巻末ぐらいでしょうか。。。

やはり，
用途，状況，設計とさまざまな要因が絡んだ上で
ベストな選択ってのはケースバイケースですものね。。。

世の中になければ！！
つくってしまおう。
ということで，
地道にモデルケース作ってパフォーマンス見てみようかなぁ。

ログインすると、みんなのコメントがもっと見れるよ