views:

103

answers:

2

I have been following along with Rob Conery's Linq for MongoDB and have come across a question. In the example he shows how you can easily nest a child object. For my current experiment I have the following structure.

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

class Profile
{
    ...
}

This works great when looking at content items. The dilemma I'm facing now is if I want to treat the Profile as an atomic object. As it stands, it appears as if I can not query the Profile object directly but that it comes packaged with Content results. If I want it to be inclusive, but also be able to query on just Profile I feel like my first instinct would be to make Profiles a top level object and then create a foreign key like structure under the Content class to tie the two together.

To me it feels like I'm falling back on RDBMS practices and that feels like I'm most likely going against the spirit of Mongo. How would you treat an object you need to act upon independently yet also want as a child object of another object?

A: 

Haven't followed Rob's stuff too much but just thinking out loud here. Couldn't you have a Profile provider object that the Content object could get at and that would have some way to fetch the instance of the Profile you are looking for.

That would favor the composition you are looking for over the parent / child relationship.

Again, thinking out loud here, but I would make the content object have a dependency of type IProfileProvider and I would inject that provider into the content object when needed. That would allow me to compose the Content type with the Profile type, while not explicitly having the parent / child relationship

Foovanadil
A: 

I've decided that denormalizing the profile to be a "smaller" profile that only contains the immutable profile properties under the content would be a better solution. This minimizes the reads I'll be making while at the same time allows me to look up the actual profile object if necessary to gather deeper data on the profile.

Jeremy B.