- PR -

RDBアプリケーションのためのパターン

«前のページへ 1|2
投稿者投稿内容
未記入
大ベテラン
会議室デビュー日: 2006/05/19
投稿数: 125
投稿日時: 2006-09-29 15:48
引用:

vincentさんの書き込み (2006-09-29 15:28) より:
私もADO.NETのこの考え方は大いに納得できるのですが、従来型データアクセスに
慣れた人から見ると強い違和感があるのも事実です。また、単体クエリーの集合を
データバインドするのも慣れが必要なので、開発現場で反対意見があがるのも
理解できます。.NETに習熟したメンバーが集まらないと厳しいでしょうね。

ついついアーキテクチャの美しさを追求しがちですが、実際は開発現場の
レベルに合わせた仕組みの導入が重要だと思っています。


現状の開発現場ではNETでの開発がはじめてという方が多いです。
またその方たちが独自の方法でRDBへの接続を行い
最終的に収集がつかなくなってしまうということもよくあります。

ですので今回はRDBへのアーキテクチャを固めたいのですが
固めすぎると複雑なパターンへの対応ができず
緩めすぎると自由気ままなコードが発生してしまいます。
がんふぃーるど
ベテラン
会議室デビュー日: 2006/06/05
投稿数: 58
お住まい・勤務地: さいたま
投稿日時: 2006-09-29 21:20
お世話になってます。がんふぃーるどです。

RDBアプリケーションのためのパターンですか。難しいですねぇ。.NETのバージョンによっても変わってきますし…

>たつごろーさん
「赤間本」はいいですね。上流工程の人にも読んで欲しい本です。vol5は秀逸だと思います。（vol5だけでなくvol2〜vol5＋ASP.NET2.0対応本全て読んだほうがもちろん良いですが）

>未記入さん
>DataSet/DataTableを使用しようと考えています。
パフォーマンスが少なからずとも重要視される場合はDataReaderを使用する方が良いとの報告（ASP.NET1.0）があります。Why I Don't Use DataSets in My ASP.NET Applications

上記の話では、DataSetはDataReaderを使用する場合よりも30倍も遅いとの結果が出ています。また、DataSetを使うのが有用な場合として、デスクトップ/ウィンドウズアプリケーションの場合や、異種プラットフォーム間でDBの内容をやり取りする場合とも書かれています。
（この結果は.NET1.1のもので、.NET2.0ではDataSetのパフォーマンスの向上が図られています。）

>ですので今回はRDBへのアーキテクチャを固めたいのですが
>固めすぎると複雑なパターンへの対応ができず
>緩めすぎると自由気ままなコードが発生してしまいます。
vincentさんの言うとおり銀の弾丸は存在しません。規模に合わせて変更すべきです。（例えば小規模の場合はDataSetをそのまま使用すればいいですし、大規模な場合はORマッピングツールと共にN階層アーキテクチャを採用する等等）

何にせよ、規模やアプリケーションの特徴などの説明が無い限り、はっきりしたことを言うのは難しいと思います。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）