0

データ取得用の検索サーバーとして Lucene を使用しています。

これに伴い、私は準備ができていなかった特定の複雑さが生じます。そのうちの少なくとも 1 つは、オブジェクト間の関係の管理です。

ドメイン オブジェクト用のクリーンでシンプルな POCO を作成したいと考えています。これらの POCO には、UI に必要な関連オブジェクトが含まれますが、他のフィールドは含まれません (これらの関係を定義する ID、UI では必要のない他のさまざまなフィールド)。

つまり、Lucene の Hits コレクションを UI フレンドリーな POCO に直接変換することはできず、少なくとも関連オブジェクトの ID を含むクラスの中間セットが必要です (同じインデックスまたは他のインデックスに格納されます)。これらの DTO オブジェクトを呼び出すのをためらっていますが、簡単にするために、そのように呼びます。

したがって、次のように機能すると想定しています。

  1. Lucene でクエリを実行 -> ヒット コレクション
  2. ヒットを繰り返す -> DTO コレクション
  3. DTO コレクション -> [関連オブジェクトを取得するサービス、POCO を作成] -> POCO
  4. 光沢のあるシンプルな POCO を使用して UI をレンダリングする

そうすることで私が恐れているのは、Anemic Domain Model ( http://www.martinfowler.com/bliki/AnemicDomainModel.html ) になってしまうことです。

これは有効な懸念ですか、それとも私は正しい道を進んでいますか?

4

2 に答える 2

1

私は、おなじみの DTO のパターンに行き着きました。DTO にはすべての ID があります。これは、Lucene から取得したレコードの単なる CLR 反映です。

次に、DTO からサービス層の POCO にマップし、それらのオブジェクトを使用して UI 要素をレンダリングします。

滑らかではありませんが、機能します。

于 2012-12-10T15:50:45.227 に答える
0

POCO に ID 情報がないと、接続されていないオブジェクトの寄せ集めが発生するだけなので、デザインは貧血に苦しむ可能性があります (すべてを一度にメモリに収めることさえできない場合があります)。また、ID がないと、キャッシングとメモ化 (オブジェクトが必要になるたびにデータベースにアクセスしないようにするのに役立ちます) が大幅に妨げられるように思えます。すべてのデータが一度にメモリに収まると思い込む余裕はめったにありません。

于 2012-12-04T23:03:05.140 に答える