c# - 3 層設計との混同

Question

Web で 3 層設計の例を確認してきましたが、ほとんどのサンプルがデータセットまたはデータ テーブルのいずれかを返すことに気付きました。私を混乱させているのは、リストの基になっている型内からプロパティまたはメソッドを利用できるように、型の汎用リストを返したい場合はどうなるかということです。データに応じて特定の方法でさまざまなフィールドを連結する Name プロパティを使用する例として、List がフォーム上のコントロールにバインドされている場合、Name プロパティをデータフィールドとして使用できます。データセットまたはテーブルを使用して同じことを達成したい場合は、データベースからデータを返して同じことを達成する必要があります (データセットまたはデータテーブルを使用しないようにしているため、このステートメントについてはおそらく非常に間違っています。 . :) )

私を本当に混乱させているのは、コードの再利用についてです。コードを再利用する唯一の方法は、データをデータセットまたはデータテーブルに取得し、データをループしてリストに追加することです。これは一般的に3層のベストプラクティス、またはデータセットとデータテーブルなしでこれを行う方法はありますか.

以下のリンクの例は、本質的にデータセットまたはテーブルを使用してオブジェクトに追加することを示していますが、これがベストプラクティスであるかどうかを尋ねざるを得ませんか?

http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET

ありがとう

Answer 1

s の使用DataTableは、特定のドットネット主義です。その背後にある理由は、データの構造に関するメタデータが含まれているためです。これにより、DataGridリフレクションなどを使用せずにデータ (およびその他のそのようなコンポーネント) を自動的に表示できます。私の推測では、これはとりわけ RAD への MS Access アプローチの遺産であり、その意図は、SQL スキーマからユーザー インターフェイスを直接生成することで、「ビジネス パーソン」がアプリケーションを作成できるようにすることでした。その後、この遺産はハイブマインドに漏れ出したようです。

RAD 機能を放棄する意思がある限り、「プレーンな」データ構造を使用することに何の問題もありません。最近の傾向は、このトレードオフも取り除くことだったようです。(たとえば、Web フォームの厳密に型指定されたデータ コントロールや、MVC のモデル バインディング機能など)。

また、より一般的に言えば、MVC が確立される前のコード プロジェクトの記事は、一般的なソフトウェア アーキテクチャに関する知識の良い情報源ではありません。

Answer 2

3 層設計を示す簡単な方法であるため、使用されているデータ テーブルとデータセットのサンプルを見つけていると思います。現在、Entity Framework は、サンプルで言及されている「データ アクセス レイヤー」の大部分を置き換えています。

エンティティ フレームワークの前に、データ アクセス レイヤーを記述したときに、データベースから構築した一般的なリストを返していました。更新、削除、または挿入を実行するには、オブジェクトをパラメーターとしてメソッドに渡し、そのオブジェクトのプロパティを SQL ステートメントの値として使用します。あなたが言及した理由だけでなく、オブジェクト定義またはデータベーススキーマを互いに独立して変更できる（または別のデータベースを一緒に使用することさえできる）ため、そのようにすることを好みました。

Answer 3

データを何に運ぶべきかは、完全にニーズによって異なります。

DB からデータを取得してデータグリッドにバインドする場合、データセットが最適なソリューションになる可能性があります。データが独自の更新ステータスを追跡する他の方法が必要な場合は、Entity Framework を調べる必要があります。データを取得し、クロス プラットフォームまたはクロス ドメイン処理のために Web サービスを介して送信する場合は、独自の他のシリアライズ可能なクラスにデータをロードする必要があります。

以下の記事をご覧ください。少し古く、EF4 を対象としていますが、さまざまな戦略の長所と短所を非常にうまくまとめています。(連載は 3 回ありますが、すべてお読みになることをお勧めします)

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx