私は、他の人が構築したライブラリやフレームワークに依存するよりも、独自の構築を好む世界の出身です。この世界から逃れた後、Visual Studio 内で型指定されたデータセットなどのツールを使用する喜びと使いやすさを発見しました。では、柔軟性の喪失以外に、他に何を失うのでしょうか? パフォーマンス要因はありますか (プロシージャと動的 SQL の議論を無視して)? 制限？
8223 次
7 に答える
14
型指定されたデータセットは、従来の ADO の切断されたレコードセットの世界からのアップグレードです。行指向のソートタスクを実行する必要がある単純な状況、つまり、行、列、制約などのデータベースパラダイムのコンテキストで作業したいという単純な状況で使用するのにまだ適していることがわかりました。そのコンテキストで賢く使用すれば、問題ありません。
それらの利点が減少するいくつかの領域があります。
- ここで提起された同期の問題は、特にそれらをカスタマイズしたり、基本クラスとして使用したりした場合は、すでに間違いなく問題であると思います。
- データセット内のデータ テーブルの数によっては、非常に太くなる可能性があります。これは、通常、複数テーブルのデータセットがデータのリレーショナル ビューを表すという意味で意味します。それに伴い、メモリ内のフットプリント以外に、キーの定義と潜在的に他の制約があります。繰り返しますが、それが必要な場合でも、一度だけデータをすばやくトラバースする必要がある場合は、データ リーダーを使用した効率的なループの方が適している可能性があります。
- それらの複雑な定義と潜在的なサイズのため、リモート処理の状況でそれらを使用することもお勧めできません.
- 最後に、問題のドメインに関連するオブジェクトでデータを操作する必要があることに気付き始めると、それらを使用することはメリットよりも障害になります。セット内の行テーブルにフィールドを出し入れしたり、テーブルや行の状態に気を配ったりしている自分に常に気付きます。オブジェクト指向言語は、現実世界の問題領域オブジェクトを表現しやすくするために作成されたものであり、テーブル、行、および列を操作することは、その考え方に実際には適合しないことに気付き始めます。
一般的に、私の経験では、複雑なシステム (多くの大規模なエンタープライズ システムなど) では、データセットの使用から離れて、堅実なドメイン固有のオブジェクト モデル (これらのオブジェクトにデータを出し入れする方法) に移行する方がよいことがわかっています。 (たとえば、ORM を使用して) は、まったく別の話題です。ただし、基本的なメンテナンスやその他の簡単な操作が必要なデータの前にフォームが配置されている小さなプロジェクトでは、特に Visual Studio/.Net の強力なデータバインディング機能と組み合わせると、データセット パラダイムを使用して優れた生産性を達成できます。
于 2008-09-10T03:09:58.617 に答える
10
私が拡張する主な批判は、それらがうまくスケーリングしないということです.軽量のビジネスエンティティ、DTO、またはLINQ to SQLと比較して、トランザクション数が増えると、オーバーヘッドが原因でパフォーマンスが低下します. スキーマ変更の頭痛の種もあります。「産業用強度」アーキテクチャの場合、それらはおそらく進むべき道ではなく、長期的には問題を引き起こすでしょう。
私は今でも間違いなくそれらを簡単で汚い PoC や単純なユーティリティに使用します。Visual Studio のツールを使用して作業し、仕事を完了するのに非常に便利です。
于 2008-09-10T02:58:17.443 に答える
5
パフォーマンスは、型指定されていないデータセットよりも型指定されたデータセットで改善されます (ただし、心配する価値のあるような些細なことでパフォーマンスの問題が発生したことはありません)。
最大の問題は、データベースとの同期を維持することだと思います.VS 2008については言えませんが、以前のバージョンはこれを適切にサポートしていません. 結果セットのスキーマが変更されるたびに、文字通りプロシージャをデザイナーにドラッグします。楽しくない。
ただし、コンパイル時の型チェックは優れており、Dataset.Tables(0).Rows(0)("Name") ではなく Customer.Name のようなものがあります。
したがって、スキーマが比較的静的な場合は価値があるかもしれませんが、そうでない場合は気にしません。
実際の ORM を調べることもできます。
于 2008-09-10T02:47:32.837 に答える
4
Typed Datasets はごく短い時間だけ試してみました。生成されたコードの 1,000 行以上のファイルの約 2/3 でコードが壊れているのを見つけたので、停止しました。
私が気に入らなかったもう 1 つの点は、Customer.Name のようなコードを記述できると思っていたのに、デフォルトでは CustomerDataSet.Customers[0].Name のようなコードを取得するように見えたことです。ここで、Customers[0] は CustomersRow 型でした。 . 型指定されていないデータセットよりも読みやすいですが、私が探していたセマンティクスではありません。
個人的には、ActiveRecord/NHibernate の道を歩み始めて以来、振り返っていません。
于 2008-09-10T02:56:55.280 に答える
2
私は型指定されたデータセットの大ファンではありません。型指定されたデータセットを使用してパフォーマンスを向上させる方法はありません。既存のデータベース オブジェクトに対する純粋なラッパーです。employee.empNameのようなアクセスは考えられません。キャストは引き続きラッパーで行われます。もう 1 つのオーバーヘッドは、大量のコードです。LOCが増加します。メモリ内の非常に多くのアクティブなオブジェクト。スキーマの自動更新はありません。いずれにせよ、型付きデータセットは、それが提供する快適さを除けば、開発者にとって役に立ちません。開発者として、私たちには快適さを要求する権利はありません :) 苦労してください... ユーザーの苦労を取り除いてください :)
于 2009-12-13T14:21:41.927 に答える
2
型指定されたデータセットに問題はありません。これらは完全ではありませんが、オブジェクト リレーショナル インピーダンスの不一致の問題を解決するための次のステップです。私が直面した唯一の問題は、スキーマ変更のサポートが弱いことです。部分クラスは役に立ちますが、すべての場合ではありません。
于 2008-09-10T02:51:14.810 に答える
1
データセットは、前述の問題がすべて無視されている場合、Visual Studio と一緒に何かをすばやく叩くのに適しています。言及されていない問題の 1 つは、Visual Studio のデザイン サーフェイス内でのデータセットの視覚的なスケーラビリティです。システムが成長するにつれて、データセットのサイズは必然的に扱いにくくなります。デザイナーの視覚的側面は単純にスケールしません。データセットに 20 以上のテーブルがある場合、特定のテーブルまたはリレーションを見つけようとしてスクロールするのは非常に面倒です。
于 2009-04-10T23:10:43.550 に答える