0

JCProperty クラス内で次のコードを使用して、DAL からデータを取得しています。

Dim x As JCProperty
        x = JCPropertyDB.GetProperty(PropertyID)

        If Not x Is Nothing Then
            Me.PropertyID = x.PropertyID
            Me.AddressLine1 = x.AddressLine1
            Me.AddressLine2 = x.AddressLine2
            Me.AddressLine3 = x.AddressLine3
            Me.AddressCity = x.AddressCity
            Me.AddressCounty = x.AddressCounty
            Me.AddressPostcode = x.AddressPostcode
            Me.TelNo = x.TelNo
            Me.UpdatedOn = x.UpdatedOn
            Me.CreatedOn = x.CreatedOn
            Me.Description = x.Description
            Me.GUID = x.GUID
        End If

これは問題なく動作しますが、DAL オブジェクト (JCPropertyDB) がビジネス オブジェクト (JCProperty) を認識している必要があり、同じオブジェクトを 2 回効果的に作成して入力します (1 回は DAL で BL に戻り、次に BL オブジェクト内で再度入力します)。自体）。

ここで何かが欠けています。もっと良い方法があるはずです!

事実上、許可されていない「Me = x」を割り当てる必要があります。誰かが私をまっすぐにすることができますか？

4

5 に答える 5

4

あなたは正しい方向に進んでいますが、わずかに 1 点足りません。

通常、データ アクセス レイヤー (DAL) は、データベースからデータ転送オブジェクト(DTO) を返します。これらはプレーン オールド CLR オブジェクト (POCO) であり、ビジネス ロジックを含まず、多かれ少なかれデータベース テーブルにマッピングされるプロパティのみです。

次に、これらの DTO からドメイン モデルを作成するコードを作成します。これはData Mapperと呼ばれます。ドメイン モデル内のクラスは似たような名前 (つまり、CustomerDTO -> Customer) を持つ場合がありますが、データに加えて、検証ルールやその他のビジネス ロジックが含まれる場合があります。

実際の DTO ではなく、ビジネス層で使用するのはこのドメイン モデルです。つまり、DAL から返された DTO を変更する場合 (つまり、新しい ORM ツールを実装することによって)、データ モデルが同じままであれば、Data Mapper を変更するだけで済みます。

データ アクセス パターンについては、 Martin Fowler の Patterns of Enterprise Application Architectureを参照することをお勧めします。

于 2008-10-14T08:12:54.930 に答える
2

これがあなたの質問に答えるかどうかはわかりませんが、重要な点は、ドメイン モデルがディスプレイからもストレージからも独立しているということです。これは、関心の分離と呼ばれることがよくあります。アイデアは、疎結合を取得し、オブジェクトがいくつかの完全に異なる責任を持たない単純なシステムを作成することです。
したがって、DAL がビジネス オブジェクトを直接作成できるようにしますが、DAL に関連するものでビジネス オブジェクトを汚染しないようにします。同様に、HTML のような UI 固有のものでそれらを汚染したくありません。私の意見では、ビジネス レイヤー、DAL、および UI レイヤーのすべてがドメイン モデルに依存することは問題ありませんが、ドメイン モデルからこれらの他のコンポーネントに依存することは問題です。
カップリングを緩めるには、Spring またはその他の Dependency Injection コンテナーをインターフェイスと配線と共に使用すると役立ちます。
すべてのレイヤーで同じオブジェクトを再作成することにより、DRY 原則に違反し (繰り返さないでください)、ボイラー プレート コードを導入し、どこかにエラーを導入する可能性を高めます。

于 2008-10-11T16:05:47.207 に答える
1

個人的には怠け者です。私は通常、次のようなことをします：

class JCProperty : inherits JCPropertyDB
   {

   New()
      {
      MyBase.New()

      GetProperty(PropertyID)

      }
   }

これで、JCPropertyDB に既に存在する機能の「上に」発生する必要がある JCProperty クラスの追加機能が得られるまで、基本的には完了です。次に、JCPropertyDB メソッドをオーバーライドして、最初に基本メソッドを呼び出してから、新しい機能を追加します。

ロン

于 2008-10-11T16:23:14.613 に答える
0

私はBOを取り込み、ブリッジパターンとプロバイダーモデルを介してDALからBOを送り返してきました。大量のシリアル化（WebサービスやJSONなど）を恐れない限り、DTOの要点を理解することはできません。私のアプローチは、インターフェースを介してデータ層とビジネス層を抽象化し、ビジネスオブジェクトにフィードされる匿名のデータ層を提供することでした。これは、任意のデータレイヤーをプラグインし、ユニバーサルなLoadメソッドとSaveメソッドを持ち、ドメインレイヤーを介してアクセスできるインターフェイスを実装できることを意味します。BLにはDALコードはありません。提供され、抽象化されたデータ層を呼び出すだけです。データレイヤーへの呼び出しはプロバイダーパターン（直接参照なし）によって管理され、単純に次のことを行います。

public class Person : IBusinessObject<Person>
{
   protected IDataLayer<T> dataLayer;

   Person Load() { this.dataLayer.Load(this); }

}

私が持っているデータレイヤーでは...

public class PersonMapper : IDataLayer<Person> 
{
    Person Load(Person person) {
    ...get DB stuff...map to person...decorate object...
       return person;
    }
}

これが良いかどうかはまだわかりませんが、私にとっては非常にうまく機能します。リフレクションを使用して、ネストされたオブジェクトに対しても遅延読み込みを行うことができました。

于 2009-10-09T11:55:23.110 に答える
0

チェックアウト: http://www.icemanind.com/layergen.aspx

于 2009-09-29T20:49:11.653 に答える