9

しばらく前にこの質問をしましたが、現在、データベース アクセス レイヤーとドメイン レイヤーを実際に分離する方法を検討しています。また、ビジネス ロジックをそれが属するドメインに移動し、コントローラー スクリプトから除外する作業も行う予定です。

データ アクセス レイヤーにテーブル データ ゲートウェイと行データ ゲートウェイ パターンを実装する Zend Framework を使用していますが、データ アクセス レイヤーとは別のドメイン レイヤーを構築する方法を実際に定義できていないようです。ドメイン ロジックがデータ アクセス ロジックと共存する Active Record パターンの使用を検討しましたが、次のような状況が少なくとも 1 回は発生し、Active Record では処理できないと思います。

person_id および userType フィールドを含む単一のテーブル「Person」があります。

各 userType (管理者、バイヤー、アソシエイト、スーパーバイザー) には、関連付けられた特定のビジネス ロジックがあり、すべてのタイプは Person オブジェクトからいくつかの基本機能を継承します。

特定の 1 つのタイプのユーザーだけに属するビジネス ロジックを使用して行データ ゲートウェイ オブジェクトを肥大化させたくはありませんが、さまざまなタイプのユーザーを表すドメイン層を構築する方法がわかりません。たとえば、PersonGateway オブジェクトを含む Person オブジェクトを作成してから、ゲートウェイ オブジェクトに呼び出しを渡すラッパー関数を作成するか、または Person オブジェクトを作成して PersonGateway オブジェクトを拡張し、必要な特定の関数のみを実装するか?

同様に、私は通常、これは (部分的に) ファクトリの問題であり、userType に基づいて正しいサブクラスをインスタンス化するファクトリ メソッドが必要であると考えています。Zend Framework の Zend_Db クラスを使用する場合、これが依然として最良の方法ですか?

Zend_Db の上にドメイン モデルを適切に作成する方法について説明しているチュートリアルへの提案やリンクは大歓迎です。

4

1 に答える 1

17

ドメインモデルは何も拡張しません。これらは、ビジネスロジックをカプセル化するために使用する単なるクラスです。それらはデータアクセスオブジェクトを使用protectedする可能性があるため、クラス内に行データゲートウェイオブジェクトのインスタンスが存在する可能性があります。オブジェクトは通常、オブジェクトよりもドメインのRowインスタンスをより厳密に表しTableます。さらに、 'sメソッドを使用していつでもTableオブジェクトを取得できます。RowgetTable()

通常、DMクラスには、そのクラスで実行できる高レベルの操作に対応するメソッドとのインターフェイスがあります。ただし、必ずしもすべてのデータアクセス操作を表面化する必要はありません。

class Person {
  // Zend_Db_Table_Row object
  protected $data; 

  public function subscribeToService(Service $service) { ... }

  public function sendMailTo(Person $recipient) { ... }

  public function changePassword($newPassword) { ... }
}

去年の春にもこのテーマについてブログを書き、最近ZFメーリングリストに書いた。

チュートリアルとリソースに関しては、http：//domaindrivendesign.org/を試してください。

于 2008-12-16T23:02:19.773 に答える