relations d'entités dans C# en utilisant la pratique mongodb

Question

J'utilise mongodb de C#.

J'ai une définition d'entité, et je veux référencer une autre entité de celle-ci. (Notez que l'intégration n'est pas une option)

Je sais que je peux insérer un champ avec l'autre id d'entité dans le premier. C'est quelque chose comme:

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;} 
    ..... 
} 

Maintenant, ici, j'insère dans mon domaine de la logique de la mécanique quelques rares.

Alors ma question est: Est-ce là des pratiques qui me permettent cacher ce genre de questions à ma couche de domaine, je veux dire dans mon domaine, je veux juste avoir quelque chose comme:

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;} 
    ..... 
} 

Dans mon domaine Je veux me concentrer sur le codage au lieu de la mécanique.

Answer 1

Ma recommandation serait de ne pas utiliser mongodb, qui est un db basé sur un document nosql aka, comme un db relationnel. La méthode recommandée pour modéliser les données dans nosql consiste à traiter chaque document comme une racine agrégée (http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-agrgregates-and-roots/), c'est-à-dire faire un la distinction entre l'entité et l'objet de valeur est très cruciale Les objets de valeur ne devraient pas avoir d'identifiants. Dans le tutoriel mongodb ci-dessous http://www.codeproject.com/Articles/87757/MongoDB-and-C

Les commentaires sont des objets de valeur. Donc, la question principale est d'animal de compagnie un objet de valeur et exige un ID. Si ce n'est pas le cas, supprimez l'ID de la classe Pet et incorporez l'animal de compagnie dans la classe Person. S'il nécessite un ID, conservez le champ ID dans la classe Pet, enregistrez-le comme son propre document et stockez l'identifiant Pet dans la classe Person. C'est le modèle recommandé pour la modélisation de données nosql. Une astuce pour évaluer si votre modèle de données convient à nosql est de se demander si ce document fournit des informations complètes pour une personne dans le contexte (une personne qui possède un animal de compagnie) dans un voyage ou un document que vous utilisez habituellement incorrectement. Bien que pour une base de données NoSQL différents les articles suivants véhiculent ce concept très bien

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- base de données

Espérons que cela aide.

Answer 2

La meilleure pratique à cet égard serait d'avoir une couche de mappage entre les objets qui contiennent des données et vos entités métier. Vos entités métier peuvent avoir l'objet Animal imbriqué entièrement disponible alors que vos objets de données ont simplement un ID.

Dans ce cas, vous devez faire très attention de ne pas vous retrouver avec un problème de sélection N + 1.

Je suis curieux de savoir pourquoi l'intégration d'un document n'est pas une option, car c'est généralement le meilleur moyen de résoudre ce problème.