C#:DataSet以外に何を使用しますか

https://stackoverflow.com/questions/18533

09-06-2019
|

質問

.Net の DataSet/DataTable/DataRow パラダイムにますます満足できなくなってきました。その主な理由は、実際にやりたいことよりもいくつかの手順が複雑であることが多いためです。コントロールにバインドする場合は、DataSet で問題ありません。しかし、他のケースでは、かなりの量の精神的なオーバーヘッドがあるようです。

SqlDataReader を少し試してみましたが、選択による単純な操作には適しているようですが、.Net には他にももっと学ぶと役立つモデルが潜んでいるような気がします。これに関するヘルプはすべて、デフォルトで DataSet を使用しているだけのような気がします。おそらく、それと DataReader が本当に最良の選択肢なのかもしれません。

私は最良/最悪の内訳を探しているのではなく、私の選択肢が何であるか、そしてあなたがそれらについてどのような経験をしたかに興味があるだけです。ありがとう！

-エリック・シップル

解決

.NET 3.5 が登場して以来、私はもっぱら LINQ を使用してきました。それは本当に素晴らしいことです。もうあの古い松葉杖を使う理由が見当たりません。

ただし、LINQ は優れていますが、どの ORM システムでもその面倒な作業を解決できると思います。

他のヒント

私たちはデータセットから離れ、大まかに基づいて独自の ORM オブジェクトを構築しました。 CSLA. 。DataSet、LINQ、ORM のいずれでも同じ作業を実行できますが、それを再利用する方が (私たちは) はるかに簡単です。「コードが少ないほど幸せになる」。

.Net 1.1 の DataSet にはうんざりしていましたが、少なくとも、大規模なセットに対して指数関数的に遅くならないように最適化されました。

これは常にかなり肥大化したモデルでした。その機能のほとんどを使用しているアプリはあまり見たことがありません。

SqlDataReader は優れていましたが、以前はそれをラップしていました IEnumerable<T> ここで、T はデータ行の型付き表現です。

私の意見では、Linq の方がはるかに優れた代替品です。

私が使ってきたのは、データ転送オブジェクトパターン (元々は Java の世界から来たものだと私は信じています) を使用し、アプリケーションの他の層で使用するためにデータ層から DTO のコレクションを設定する SqDataReader を使用します。DTO 自体は、get/set を持つプロパティで構成される非常に軽量で単純なクラスです。これらは簡単にシリアル化/逆シリアル化でき、データバインディングに使用できるため、ほとんどの開発ニーズに非常に適しています。

私は大ファンですサブソニック. 。適切に作成されたバッチ/CMD ファイルを使用すると、データベースのオブジェクトモデル全体を数分で生成できます。これを独自の DLL にコンパイルし、必要に応じて使用できます。素晴らしいモデル、素晴らしいツール。このサイトは ASP.NET の取引のように聞こえますが、一般的に言えば、UI フレームワーク (私はかなりがっかりしました) やアプリケーションレベルの自動生成ツールを使用しない限り、ほぼどこでも問題なく動作します。。

記録のために、これを操作するために私が使用するコマンドのバージョンを次に示します (最初はあまり苦労する必要がないように)。

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true

それは毎回そうなります...次に、そのディレクトリから DLL をビルドします。これは、CruiseControl.NET によって開始される NAnt プロジェクトの一部です。そして、先に進みます。私はこれを WinForms、ASP.NET、さらにはいくつかのコマンドラインユーティリティでも使用しています。これにより、依存関係が最小限に抑えられ、最大の「移植性」が実現されます (関連プロジェクト間、EG)。

注記

上記の内容は 1 年以上前のものです。私は今でも SubSonic に大きな思い入れを持っていますが、.NET 3.5 で作業する余裕ができたので、LINQ-to-SQL に移行しました。.NET 2.0 では、依然として SubSonic を使用しています。したがって、私の新しい公式アドバイスはプラットフォームのバージョンに依存します。.NET 3 以降の場合は、受け入れられた回答をそのまま使用してください。.NET 2.0 の場合は、SubSonic を使用してください。

DataSet はデモに最適です。

私に使わせたらどうすればいいのかわかりません。

ObservableCollectionを使用します

そして再び私はクライアントアプリの領域、WPF と Silverlight にいます。したがって、サービスを介してデータセットまたはデータテーブルを渡すことは...きもい。

DataReader は結果セットの前方専用ストリームであるため、高速です。

私は、型付きおよび型なしの DataSet、DataViewManagers、DataView、DataTables、DataRows、DataRowViews をはじめ、スタックが複数のエンタープライズプロジェクトで最初に登場して以来、このスタックで実行できるほぼあらゆるものを使用してきました。この許可の仕組みに慣れるまでにしばらく時間がかかりました。ADO.NET では本当に必要なものが得られなかったため、スタックを利用するカスタムコンポーネントを作成しました。このようなコンポーネントの 1 つは、DataSet を比較し、バックエンドストアを更新します。私はこれらすべてのアイテムがどのようにうまく機能するかを本当に知っています。そして、私がやったことを見た人たちは、それがデモでの使用にのみ役立つものであると私がなんとかそこを越えることができたことに非常に感銘を受けています。

Winforms で ADO.NET バインディングを使用し、コンソールアプリでもコードを使用します。私は最近、別の開発者とチームを組んで、通常のデータストアとはまったく似ていない請負業者から提供されたクレイジーなデータモデルに対して使用するカスタム ORM を作成しました。

今日、ADO.NET の代替品を探しましたが、現在使用しているものを置き換えるために真剣に学習すべきことは何も見つかりませんでした。

私はこれらを頻繁に使用していますが、このフレームワークが最初に登場したときに Microsoft が実際に推し進めていた「高度な」機能はまったく利用していません。私は基本的にこれらをハッシュテーブルのリストとして使用しているだけですが、これは非常に便利だと思います。

複雑な型の DataSet を作成しようとしたり、DataSet を使用してテーブル間の外部キー関係を実際に設定しようとしたりした場合、私は良い結果を見たことがありません。

もちろん、私はエンティティオブジェクトインスタンスよりも DataRow を実際に好む、変わった人間の 1 人です。

linq 前は DataReader を使用して独自のカスタムドメインオブジェクトのリストを入力していましたが、linq 後は L2S を使用して L2S エンティティを入力するか、L2S を使用してドメインオブジェクトを入力しています。

もう少し調査する時間が取れたら、Entity Framework オブジェクトが私の新しいお気に入りのソリューションになると思います。

最新の、安定した、積極的にサポートされている ORM ツールを選択することは、おそらく中程度の規模と複雑さのほぼすべてのプロジェクトで得られる生産性の最大の向上に違いありません。絶対に、絶対に、絶対に独自の DAL と ORM を作成する必要があると結論付けている場合は、おそらくやり方が間違っています (または、世界で最も不明瞭なデータベースを使用していることになります)。

生のデータセットや行などを処理している場合は、ORM を 1 日かけて試してみると、列をフィールドにマッピングしたり、常にデータを入力したりする単調な作業をしなくても、どれほど生産性が向上するかに驚かれるでしょう。 SQL コマンドオブジェクトやその他すべてのフープジャンプは、誰もが一度は経験したことがあるでしょう。

私は Subsonic が大好きですが、デモやプロトタイプを伴う小規模なプロジェクトの場合は、Linq to Sql も非常に便利だと思います。でも、私はEFが大嫌いです。:P

私はいくつかのプロジェクトで型指定された DataSet を使用しました。これらはデータベースを適切にモデル化し、クライアント側で制約を強制し、特に TableAdapters を使用した .NET 2.0 の変更では、一般に堅牢なデータアクセステクノロジです。

型指定された DataSet は、「肥大化」などの感情的な言葉を使って説明するのを好む人々から悪く言われます。確かに、私は DataSet を使用するよりも、優れた O/R マッパーを使用する方が好きです。型指定された DataTable や DataRow などの代わりに、オブジェクトやコレクションを使用する方が「良い」ように感じます。しかし、私が発見したのは、何らかの理由で O/R マッパーを使用できない、または使用したくない場合は、十分に使いやすく、90% の機能を実現できる型付き DataSet が適切な選択肢であるということです。 O/R マッパーの利点。

編集：

ここには、DataReaders が「高速」な代替手段であると示唆する人もいます。しかし、Reflector を使用して DataAdapter (DataTable を埋める) の内部を確認すると、DataReader が使用されていることがわかります。型付きデータセット 5月他のオプションよりもメモリ占有量が大きくなりますが、これが明確な違いを生むアプリケーションをまだ見たことがありません。

作業に最適なツールを使用してください。「気持ち悪い」や「肥大化」など、事実に基づいていない感情的な言葉に基づいて決定を下さないでください。

私はビジネスオブジェクトを最初から構築するだけで、最初にビジネスオブジェクトにデータを設定する場合を除いて、DataTable、特に DataSet をほとんど使用しません。独自に構築する利点は、テストのしやすさ、タイプセーフティとインテリセンス、拡張性 (DataSet に追加してみてください)、読みやすさ (Convert.ToDecimal(dt.Rows[i]["blah"].ToString() のようなものを読むのが好きでない限り) です。））。

もっと賢明であれば、ORM やサードパーティの DI フレームワークも使用するでしょうが、まだそれらの必要性を感じていません。私は小規模なプロジェクトや大規模なプロジェクトへの追加を数多く行っています。

データセットは決して使用しません。これらは、（誰かがここで指摘したように）「デモウェア」でのみ使用できる、大きくて重量のあるオブジェクトです。ここには素晴らしい代替手段がたくさんあります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow