2010-04-09 8 views
2

J'ai suivi avec Linq de Rob Conery pour MongoDB et j'ai rencontré une question. Dans l'exemple, il montre comment vous pouvez facilement imbriquer un objet enfant. Pour mon expérience actuelle, j'ai la structure suivante.Objets enfants dans MongoDB

class Content 
{ 
    ... 
    Profile Profile { get; set; } 
} 

class Profile 
{ 
    ... 
} 

Cela fonctionne très bien lorsque vous consultez des éléments de contenu. Le dilemme auquel je fais face est maintenant si je veux traiter le profil comme un objet atomique. En l'état, il semble que je ne puisse pas interroger directement l'objet Profile, mais qu'il soit livré avec des résultats de contenu. Si je veux qu'il soit inclusif, mais aussi capable d'interroger simplement Profile, je pense que mon premier instinct serait de faire de Profiles un objet de haut niveau et ensuite de créer une structure de type foreign key sous la classe Content pour lier les deux ensemble. Pour moi, c'est comme si je me rabattais sur les pratiques de SGBDR et que j'avais l'impression d'aller probablement à l'encontre de l'esprit de Mongo. Comment traiteriez-vous un objet sur lequel vous devez agir de manière indépendante tout en voulant également être un objet enfant d'un autre objet?

Répondre

0

J'ai décidé de dénormaliser le profil pour qu'il soit un profil "plus petit" qui ne contienne que les propriétés de profil immuables sous le contenu serait une meilleure solution. Cela minimise les lectures que je vais faire tout en me permettant en même temps de rechercher l'objet de profil réel si nécessaire pour recueillir des données plus profondes sur le profil.

0

N'a pas trop suivi les trucs de Rob mais juste à y penser à voix haute. Vous ne pourriez pas avoir un objet fournisseur de profil que l'objet de contenu pourrait obtenir et qui aurait un moyen de récupérer l'instance du profil que vous recherchez.

Cela favoriserait la composition que vous recherchez par rapport à la relation parent/enfant. Encore une fois, en réfléchissant à haute voix ici, mais je voudrais faire de l'objet de contenu une dépendance de type IProfileProvider et je voudrais injecter ce fournisseur dans l'objet de contenu en cas de besoin. Cela me permettrait de composer le type Content avec le type Profile, sans avoir explicitement la relation parent/enfant

Questions connexes