.NetのDataSet/DataTable / DataRowパラダイムにますます不満を感じています。これは主に、実際にやりたいことよりも2、3ステップ複雑なことが多いためです。コントロールにバインドしている場合は、DataSetで問題ありません。しかし、他の場合には、かなりの量の精神的なオーバーヘッドがあるようです。
私はSqlDataReaderで少し遊んだことがあり、それはselectを介した単純な冗談には良いようですが、.Netには、詳細を知るのに役立つ他のモデルが潜んでいる可能性があると思います。私がこれで見つけたすべてのヘルプは、デフォルトでDataSetを使用しているように感じます。多分それとDataReaderは本当に最良のオプションです。
私は最良/最悪の内訳を探しているのではなく、私の選択肢が何であるか、そしてあなたがそれらでどのような経験をしたかを知りたいだけです。ありがとう！
-エリック・シップル
.NET 3.5がリリースされて以来、私はLINQのみを使用してきました。それは本当に良いことです。これらの古い松葉杖を使用する理由はもうありません。
ただし、LINQは素晴らしいですが、どのORMシステムでもその問題を解決できると思います。
データセットから離れて、 CSLAに基づいて独自のORMオブジェクトを大まかに構築しました。DataSet、LINQ、ORMのいずれかを使用して同じ作業を行うことができますが、それを再利用する方がはるかに簡単です（私たちが見つけました）。「コードが少ないほど幸せになります」。
私は、SqDataReaderでデータ転送オブジェクトパターン（元々はJavaの世界からのもの）を使用して、アプリケーションの他のレイヤーで使用するためにデータレイヤーからDTOのコレクションを設定してきました。DTO自体は非常に軽量で単純なクラスであり、gets/setsを持つプロパティで構成されています。これらは簡単にシリアル化/逆シリアル化でき、データバインディングに使用できるため、私の開発ニーズのほとんどに非常に適しています。
私は .Net 1.1 の DataSet にうんざりしていました。少なくとも、大規模なセットで指数関数的に遅くならないように最適化しました。
それは常にかなり肥大化したモデルでした - 私はその機能のほとんどを使用する多くのアプリを見たことがありません.
SqlDataReader は優れていましたが、IEnumerable<T>以前は T がデータ行の型付き表現である でラップしていました。
私の意見では、Linq ははるかに優れた代替品です。
私はSubSonicの大ファンです。適切に作成されたバッチ/CMD ファイルは、データベースのオブジェクト モデル全体を数分で生成できます。それを独自の DLL にコンパイルし、必要に応じて使用できます。素晴らしいモデル、素晴らしいツール。このサイトは ASP.NET 契約のように聞こえますが、一般的に言えば、UI フレームワーク (私はそこそこがっかりしています) やアプリケーション レベルの自動生成ツールを使用しないのであれば、どこでも素晴らしく機能します。 .
記録のために、ここで私がそれを操作するために使用するコマンドのバージョンを示します (最初にあまり苦労しなくて済むように):
sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true
これは毎回実行されます...次に、そのディレクトリから DLL をビルドします。これは NAnt プロジェクトの一部であり、CruiseControl.NET によって開始されます。私はそれを WinForms、ASP.NET、さらにはいくつかのコマンドライン ユーティリティで使用しています。これにより、依存関係が最も少なくなり、「移植性」が最大になります (関連するプロジェクト間、EG)。
ノート
上記は現在、1年以上前のものです。私はまだ SubSonic に大きな愛着を持っていますが、.NET 3.5 で作業する余裕があるときに LINQ-to-SQL に移行しました。.NET 2.0 では、まだ SubSonic を使用しています。したがって、私の新しい公式アドバイスは、プラットフォームのバージョンに依存します。.NET 3+ の場合は、受け入れられた回答を使用してください。.NET 2.0 の場合は、SubSonic を使用します。
型付きおよび型なしの DataSet、DataViewManager、DataView、DataTable、DataRow、DataRowView など、スタックが最初に複数のエンタープライズ プロジェクトで登場して以来、スタックで実行できるほぼすべてのことを使用してきました。それがどのように機能するかに慣れるのに少し時間がかかりました。ADO.NET では本当に必要なものが得られなかったため、スタックを活用するカスタム コンポーネントを作成しました。そのようなコンポーネントの 1 つは、DataSet を比較し、バックエンド ストアを更新します。私はこれらの項目がすべてうまく機能することを本当に知っており、私が行ったことを見た人は、デモ用にしか役に立たなかったと感じることができたことに非常に感銘を受けています.
私は Winforms で ADO.NET バインディングを使用し、コンソール アプリでもコードを使用しています。私は最近、別の開発者とチームを組んでカスタム ORM を作成し、請負業者から提供された通常のデータ ストアとはまったく異なるクレイジーなデータモデルに対して使用しました。
今日、ADO.NET の代替品を探しましたが、現在使用しているものを置き換えるために真剣に学ぶべきものは何もありません。
データセットはデモに最適です。
あなたが私にそれを使わせたら、私はそれをどうしたらいいのか分かりません。
ObservableCollectionを使用します
それからまた、私はクライアントアプリスペース、WPFとSilverlightにいます。したがって、データセットまたはデータテーブルをサービスに渡すことは...大まかなことです。
DataReaderは、結果セットの転送専用ストリームであるため、高速です。
私はそれらを広範囲に使用していますが、フレームワークが最初に登場したときにMicrosoftが実際に推進していた「高度な」機能は使用していません。私は基本的にそれらをハッシュテーブルのリストとして使用しているだけで、これは完全に便利だと思います。
複雑な型のデータセットを作成しようとしたり、データセットを使用してテーブル間の外部キー関係を実際に設定しようとしたりしたときに、良い結果は得られませんでした。
もちろん、私はエンティティオブジェクトインスタンスよりもDataRowを実際に好む奇妙な人の1人です。
最新の、安定した、積極的にサポートされている ORM ツールを選択することは、中程度のサイズと複雑さのプロジェクトについて、生産性を最大に向上させる可能性があります。絶対に、絶対に、絶対に独自の DAL と ORM を作成する必要があると結論付けている場合は、おそらく間違っています (または、世界で最もあいまいなデータベースを使用しています)。
未加工のデータセットと行を処理している場合、またはそうでない場合は、ORM を試すために 1 日を費やしてください。列をフィールドにマッピングしたり、常にデータを入力したりするという面倒な作業がなくても、生産性が大幅に向上することに驚かれることでしょう。 Sql コマンド オブジェクトと、私たちが一度経験した他のすべてのフープ ジャンプ。
Subsonic が大好きですが、デモやプロトタイプを伴う小規模なプロジェクトでは、Linq to Sql も非常に便利だと思います。私は情熱を持ってEFを嫌います。：P
linq 前は DataReader を使用して独自のカスタム ドメイン オブジェクトの List を埋めていましたが、linq 後は L2S を使用して L2S エンティティを埋めたり、L2S を使用してドメイン オブジェクトを埋めたりしています。
もう少し調査する時間があれば、Entity Framework オブジェクトが私の新しいお気に入りのソリューションになるのではないかと思います。
いくつかのプロジェクトで型指定された DataSet を使用しました。それらはデータベースを適切にモデル化し、クライアント側に制約を適用し、特に TableAdapter を使用した .NET 2.0 の変更により、一般的に堅実なデータ アクセス テクノロジです。
型指定された DataSet は、それらを説明するために「肥大化」などの感情的な言葉を使用するのが好きな人から悪い評判を受けます。私は、DataSet を使用するよりも優れた O/R マッパーを使用する方が好きだと認めます。型指定された DataTables や DataRows などの代わりに、オブジェクトとコレクションを使用する方が良いと感じるだけです。しかし、何らかの理由で O/R マッパーを使用できない、または使用したくない場合は、 DataSet は、使いやすく、O/R マッパーの利点の 90% を享受できる、堅実な選択肢です。
編集：
ここでは、DataReaders が「高速な」代替手段であると示唆する人もいます。しかし、Reflector を使用して DataAdapter (DataTable が満たされている) の内部を調べると、それが DataReader を使用していることがわかります。型指定されたDataSetは、他のオプションよりもメモリ フットプリントが大きい可能性がありますが、これが具体的な違いを生むアプリケーションをまだ見ていません。
仕事に最適なツールを使用してください。事実に基づかない「グロス」や「肥大化」などの感情的な言葉に基づいて決定を下さないでください。
私は自分のビジネス オブジェクトをゼロから構築するだけで、最初にビジネス オブジェクトを設定する場合を除いて、 を使用することはほとんどなくDataTable、特に を使用することはもうありません。DataSet独自のものを作成する利点は、テスト容易性、タイプ セーフと IntelliSense、拡張性 ( に追加してみてくださいDataSet)、および読みやすさ ( のようなものを読むのが好きでない限りConvert.ToDecimal(dt.Rows[i]["blah"].ToString())) です。
私がもっと賢かったら、ORM とサードパーティの DI フレームワークも使用したいのですが、それらの必要性をまだ感じていません。私は、小規模なプロジェクトや大規模なプロジェクトへの追加を数多く行っています。
私は決してデータセットを使用しません。それらは、「デモウェア」にのみ使用できる（誰かがここで指摘したように）大きな重量のオブジェクトです。ここに示されている素晴らしい選択肢がたくさんあります。