私は 3 層アーキテクチャを作成するプロジェクトに取り組んでいます。データ テーブルがデータ層から来るので、データ テーブルをプレゼンテーション層に直接渡すことができるかどうかを尋ねる必要があります。それは良い習慣ですか?
4 に答える
はい、できますが、良い習慣ではありません。DB のデータ テーブルごとに Entity クラスを用意することをお勧めします。各クラスには、DB 列に似たパブリック プロパティがあります。これらはすべて、ビジネス層の下にある必要があります。データ アクセス レイヤーでは、DB からデータ テーブルの形式でデータを取得し、ビジネス レイヤーに渡し、このテーブルをエンティティ オブジェクトのコレクションに変換して、プレゼンテーション レイヤーに渡します。
IMHOあなたの質問は非常に議論の余地があります
このような場合に決定を下すには、以下の点を考慮してください。
- データベース プロバイダーが、ADO.NET、Entity Framework、またはその他の ORM を使用してカスタム実装されている場合は、POCO クラスに変更し、それらの POCO インスタンスを渡して DataTable を使用しないでください。
- POCO クラスを作成できるように結果が固定されていない場合は、DataTable を使用します。
ここで、3 層アーキテクチャでの DataTable の使用に関する古い記事を確認してください。
詳細については、POCO と DataTable を使用するオンラインの利点をお読みください。
Csページで........
public DataTable dtDistinctFRU;
dtDistinctFRU= dsData.Tables[0];
aspxページで........
<% foreach (System.Data.DataRow row in dtDistinctFRU.Rows)
{
%>
....some html ...
<% Response.Write(rowNum); %>
同一のオブジェクトを通過させる場合、なぜこれらの異なるレイヤーが最初に必要になるのでしょうか? とにかく、これはアーキテクチャの問題であるため、これに対する正しい答えはありません。意見だけです。
私の意見: CRUD オペレーションではなく、オペレーションがビジネス オペレーションであることが好きです。ビジネス オペレーションを完了するために必要なものだけを渡し、クエリの場合は、UI に本当に必要なものだけを返します。これは、一般的なデータ テーブルではなく、特定のデータ コントラクトを設計することを意味します。これは、データ レイヤーがデータ エンティティと連携し、これらをドメイン エンティティにマップすることを意味します (たとえば、最初に EF コードを使用します)。次に、これらのドメイン エンティティがサービスのデータ転送オブジェクトにマップされます。UI で使用します。
http://tinyurl.com/d99w8rlでシリーズを読んで、インスピレーションを得ることができます (特にパート 2)。