13

たとえば、Person（ID、Nameなど）というデータベーステーブルがある場合、データアクセス層はどのような種類のオブジェクトをビジネス層に戻す必要がありますか？私はこのようなことを考えています：

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

しかし、これはすべて少し面倒に思えますか？この問題に対するより洗練された解決策はありますか？代わりに、データアクセス層からビジネス層にDataRowを返す必要がありますか？

4

4 に答える 4

21

データ アクセス レイヤー (DAL) でクラス定義を繰り返す必要はありません。

ビジネスエンティティを別のアセンブリで「ダム」コンテナとして作成できます。たとえば、 Person クラスは次のようになります。

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

次に、DAL にビジネス エンティティ レイヤーへの参照を与えることができます。コントローラー オブジェクトは、別のビジネス ロジック レイヤーにあるか、UI レイヤー内にあるかに関係なく、DAL を呼び出すだけで、ビジネス エンティティを作成し、データベースからデータを取り込み、コントローラーに返すことができます。

Imar Spaanjaars によるこの記事では、このパターンについて適切に説明しています。

于 2009-02-05T23:00:26.030 に答える
6

ビジネス レイヤーは、データ行について知りたくないことは間違いありません。データ固有のクラスをデータ レイヤーに残すようにしてください。これにより、カップリングが減少し、大規模な再構築を行うことなく、後で永続化レイヤーを自由に変更できます。

特定の問題を解決するには、次のいずれかを実行できます。

  • データ レイヤーで基本的なデータ オブジェクト/エンティティを作成し、それらをビジネス レイヤーに渡して使用します。
  • または、あなたが行っているように、データ層から上位層のビジネス オブジェクトのより豊富な実装にデータを転送する手段として純粋に存在する DTO (データ転送オブジェクト) を作成します。これは、リッチ ドメイン モデルのリポジトリ パターンの一部として行うことができます。

もう 1 つ考えておきたいのは、ティア v レイヤーです。これらのことをどう考えるかによって違いが生じます。層は一般に物理的です。つまり、層はプロセス間の境界を定義します。レイヤーは一般に論理的であり、プログラムの機能を疎結合のユニットに分離します。この場合、レイヤーを目指しています。

于 2009-02-05T23:11:24.760 に答える
1

DAO クラスへのインターフェイスを作成し、それらをビジネス層内に配置すると、データ アクセス層からビジネス層を参照できます。データ層の DAO クラスは、ビジネス層からオブジェクトを返します。

ビジネス層は、データ アクセス オブジェクトを直接参照するのではなく、インターフェイスを参照します。IoC コンテナー (Castle Windsor など) を介した依存性注入により、これを実現できます。

この手法は分離インターフェースと呼ばれ、ここで説明されています。

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

私が見たこの手法の最良の説明は、Billy McCafferty によって書かれた NHibernate のベスト プラクティスに関するこの記事にあります。

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

この記事には NHiberbate に固有の情報がたくさんありますが、そのかなりの半分は、アプリケーションを疎結合して簡単に単体テストできるように設計するための確かな情報です。

于 2009-02-06T00:09:44.143 に答える
0

すべてのレイヤーが上位レイヤーに疎結合する必要があるというこのルールとして、BL 参照を DAL に追加することはお勧めできません。インターフェイスを使用してDALでデータモデルを定義し、BLでBusiness Entityフォームを作成する方が適切です。私の経験では、DAL でリポジトリを使用し、ビジネス エンティティまたはビジネス プロセスでアクセスする方がよいでしょう。

于 2013-05-07T07:10:24.500 に答える