1

私は Data Mapper を使用してドメイン モデルに Fowler パターンを利用してきましたが、CRUD の作成部分を実装する方法について混乱に陥りました。基礎となるデータ ソースがカスタム システムであるため、既存の ORM テクノロジを利用できません。私を悩ませているのは、新しいオブジェクトを作成する必要があるときに、下にある ORM を呼び出す方法です。私のドメイン層は、私のファインダーを除いて、私の ORM の可視性を持っていません。

正しい軌道に乗っているかどうかはわかりませんが、表示できる唯一のオプションは次のとおりです。

  1. Fowler finder と同じ方法で create 関数を処理します。ORM クラスの作成メソッドのドメイン モデル レイヤーにインターフェイスを作成します。次に、ドメイン モデルで DI コンテナーを呼び出し、インターフェイスに基づいて ORM クラスのインスタンスをインスタンス化します。

  2. ORM でのオブジェクト A のハイドレーション中に、オブジェクト B の ORM の作成メソッドを指すデリゲートをアタッチします。ドメイン オブジェクト A がハイドレートされることを要求すると、オブジェクト B のマッパーで create メソッドを呼び出すオブジェクト A でデリゲートを呼び出すことができます。

  3. ???

これはそれほど複雑ではないので、何かが欠けているに違いありません。どんな助けでも大歓迎です。

ありがとう

4

4 に答える 4

2

ORM がこの問題をどのように解決するか見てみませんか? オブジェクトの動的作成をサポートする言語では、データがドメイン オブジェクトにどのように関連するかの「マッピング」が別の構成として提供されます。クラスは、リフレクションまたはバイトコード ライブラリによって作成されます。それは、Data Mapper をどの程度一般化したいかによると思います。元のパターン データ マッパーから収集できるものから、ドメイン オブジェクトごとに存在できます。

おそらく、一般的な解決策を試みているのでしょう。それ以外の場合は、リフレクションを使用してオブジェクトを構築する方法に関する情報を使用して一般的なマッパーを構成することについてかもしれません。

つまり、現在、ORM レイヤーは、CanonicalClass 名 + それらのクラスで期待されるメソッドのリストを表す文字列を処理できます。

永続化するオブジェクトを渡すと、この情報を使用してオブジェクトを検査できます。オブジェクトの作成は、データベースからのデータを使用したリフレクションを使用して実行できます。一部の ORM ソリューションは、オブジェクト ツリーを深く作成せず、代わりに遅延フェッチ用のプロキシを作成する場合があります。

于 2009-06-04T19:02:58.433 に答える
1

問題がタイプ A からタイプ B へのマッピングだけである場合は、AutoMapperを検討することをお勧めします。

于 2009-06-04T19:08:34.613 に答える
0

リチャードが提案したように、.NETに実装している場合は、AutoMapperを確認してください。Javaで実装している場合は、ModelMapperを確認してください。

于 2011-06-24T05:18:49.170 に答える
0

Re: 「新しいオブジェクトを作成する必要があるときに、基になる ORM を呼び出す方法」

AGGREGATE ROOT と REPOSITORY パターンのアイデアを調べたことがありますか - それらは役に立つかもしれません。

大まかな要約として: AGGREGATE ROOT は、システム内でグローバルに一意の ID を持つ「エンティティ」です。ほとんどの場合、これらは、アプリケーションが「id で」グラブする必要がある唯一のオブジェクトです。それらは、アプリケーションの起動/ブートストラップ時にデータ層を認識するために通常初期化される REPOSITORY を通じて検出されます。

AGGREGATE ROOT の FACTORIES も、通常、アプリケーションの起動/ブートストラップ時にデータ層を認識するために初期化されます。

その後、リポジトリは、オブジェクトのデータを掘り起こすプロセスを任意の方法で仲介できます。REPOSITORY は生データを取得するためにデータレイヤー/マッパーに委譲し、オブジェクト再構成の実際のジョブを FACTORY (クラス / メソッド) に委譲して構築を行う傾向があります。その後、REPOSITORY は新しく再構成された AGGREGATE ROOT オブジェクトまたは (コレクション- of) REPOSITORY の find メソッドを呼び出したクライアント、つまりアプリケーションに。REPOSITORY は、AGGREGATE ROOT を取得して保存するためのインターフェイスであり、メモリ内に格納されているそれらの動作を提供します。

ただし、アプリケーションは FACTORY を直接使用して、まったく新しい AGGREGATE ROOT オブジェクトを作成する場合があります。

AGGREGATE ROOT の Factory は、ORM/Mapper Layers について十分な知識を持っており、新しいエンティティの作成時に、ある種の「数列オブジェクト」のサービスを呼び出して一意の ID を取得する場合があります。

AGGREGATE ROOT は、通常、「グローバルに知られている ID で検索」する必要がある唯一の種類のドメイン オブジェクトです。これは、他のドメイン オブジェクトが次のいずれかであるためです。

  • 使い捨て価値のあるオブジェクト - お金の価値など、または
  • 'AGGREGATE ROOT 依存' エンティティ。つまり、次のことを意味する AGGREGATE ROOT のコンテキスト内でのみ一意の ID を持つオブジェクト
    • AGGREGATE ROOTは、実際にそれを見つけて使用する必要がある唯一のものであるべきです-内部的に
    • それらは、AGGREGATE ROOT の ORM マッパーを使用して見つけることができます。
    • それらの ID は、コンテキスト/スコープを定義する AGGREGATE ROOT によって作成できます。

参考文献：

ドメイン駆動設計、Eric Evans を参照してください。

集約ルート: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false

リポジトリ: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false

于 2010-01-22T11:31:24.043 に答える