現在のプロジェクトでは、データ セット開発モデルと 3 層構造が使用されています。
実際、3 層であるかどうかに関係なく、データ ソース コントロールを使用する最大の利点は、以前は複数テーブル関連のクエリが必要でしたが、現在はその多くがデータ ソース コントロールによって削除できることです。自動的にそれを手伝ってくれます;) とてもリラックスできて楽しいと思いませんか?
たとえば、テーブル A には ID1、ID2、ID3 という 3 つの外部キーがあります。必要なのは、3 つのフィールドをテンプレートに変換し、3 つのデータ ソース コントロールにバインドする適切なコントロールを選択することだけです。はい、残りのことは心配する必要はありません。
次に、データ ソース コントロールのうち、objdatasource は非常に使いやすいです。他のデータ ソース コントロールは単純すぎるか、特化されています (サイトマップ)。3 層構造の連携によってのみ、データ ソース コントロールの力を最大限に発揮できます。手書きで書けることは、objD でできないことにはまだ出会っていません。しかし、「頭を変える」、考え方を切り替える必要があります。実際、実装はコードを手動で記述することと同じではありません。以前は他の人のプロジェクトのバックグラウンドで 1 ページのコードが使用されていましたが、現在は 400 行未満しか使用していません。これは、objD には依然としていくつかの点で利点があると言わざるを得ません。
また、アダプターを構築するときは、生成されるデータ型がデータベースと一致しているかどうかに注意する必要があります。特に、char(1) 型は通常、byte に設定されます。コードは正しいが、エラーが発生します。が問題になることがよくあります。修正するだけでOKです
http://www.cnblogs.com/emilchan/archive/2006/11/30/578033.html