0

C＃のmongodbを使用しています。

エンティティ定義があり、このエンティティから別のエンティティを参照したい。（埋め込みはオプションではないことに注意してください）

最初のエンティティIDに他のエンティティIDを持つフィールドを挿入できることを知っています。それは次のようなものです：

class Person
{
    public object Id { get; set; }
    public string Name { get; set; }
    public object Pet { get; set; }  // note here I have the pet Id and not the pet.
}


class Pet
{
    public object Id{get;set;}
    .....
}

さて、ここで私は私のドメインロジックビジネスにいくつかの珍しいメカニズムを挿入しています。

次に、私の質問は次のとおりです。この種の問題をドメインレイヤーに隠すことができるプラクティスはありますか。つまり、私のドメインでは、次のようなものが必要です。

class Person
{
   public object Id { get; set; }
   public string Name {get; set; }
   public Pet Pet { get; set; }  // note here I have the pet.
}


class Pet
{
   public object Id{get;set;}
   .....
}

私のドメインでは、メカニズムではなくコーディングに焦点を当てたいと思っています。

4

2 に答える 2

3

私の推奨事項は、リレーショナルデータベースとしてnosql別名ドキュメントベースのデータベースであるmongodbを使用しないことです。nosqlでデータをモデル化するための推奨される方法は、各ドキュメントを集約ルート（http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/）として扱うことです。エンティティと値オブジェクトの区別は非常に重要です。値オブジェクトにはIDを付けないでください。以下のmongodbチュートリアル http://www.codeproject.com/Articles/87757/MongoDB-and-C

コメントは値オブジェクトです。したがって、主な質問は値オブジェクトをペット化し、IDを要求することです。そうでない場合は、PetクラスからIDを削除し、Personクラス内にペットを埋め込みます。IDが必要な場合は、PetクラスにIDフィールドを保持し、それを独自のドキュメントとして保存して、PetIDをPersonクラスに保存します。これは、nosqlデータモデリングに推奨されるパターンです。

データモデルがnosqlに適しているかどうかを評価するための巧妙なトリックは、このドキュメントが1回の旅行またはドキュメントでコンテキスト内の人（ペットを飼っている人）の完全な情報を提供するかどうかを自問することです。別のnosqlデータベースの場合でも、次の記事はこの概念を非常によく伝えています

http://ayende.com/blog/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases http://ayende.com/blog/4466/that-no -sql-thing-modeling-documents-in-a-document-database

お役に立てれば。

于 2012-09-24T19:37:54.117 に答える
1

この点でのベストプラクティスは、データを保持するオブジェクトとビジネスエンティティの間にマッピングレイヤーを作成することです。データオブジェクトが単にIDを持っている間、ビジネスエンティティはネストされたペットオブジェクトを完全に利用可能にすることができます。

この場合、N+1選択の問題が発生しないように十分に注意する必要があります。

ドキュメントを埋め込むことがオプションではない理由については、一般的にこれに対処するための最良の方法であるため、興味があります。

于 2012-09-24T18:56:46.257 に答える