Дочерние объекты в MongoDB

Question

Я следил за Linq Роба Конери для MongoDB и натолкнулся на вопрос. В примере он показывает, как вы можете легко вложить дочерний объект. Для моего текущего эксперимента у меня есть следующая структура.

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

class Profile
{
    ...
}

Это прекрасно работает при просмотре контента. Дилемма, с которой я сейчас сталкиваюсь, заключается в том, хочу ли я рассматривать Профиль как атомарный объект. В нынешнем виде мне кажется, что я не могу напрямую запросить объект Profile, но он поставляется с результатами содержимого. Если я хочу, чтобы он был инклюзивным, но также мог запрашивать только профиль, я чувствую, что мой первый инстинкт - сделать профили объектом верхнего уровня, а затем создать структуру внешнего ключа, подобную структуре класса Content, чтобы связать их вместе.

Мне кажется, что я прибегаю к практике СУРБД, и мне кажется, что я, скорее всего, иду против духа Монго. Как бы вы относились к объекту, на который вам нужно воздействовать независимо, но также хотите, чтобы он был дочерним объектом другого объекта?

Answer 1

Я решил, что денормализация профиля как «меньшего» профиля, который содержит только неизменяемые свойства профиля под содержимым, была бы лучшим решением. Это сводит к минимуму число операций чтения, которые я буду выполнять, и в то же время позволяет при необходимости искать фактический объект профиля, чтобы собрать более глубокие данные в профиле.

Answer 2

Не слишком много следил за вещами Роба, а просто думал вслух. Не могли бы вы иметь объект провайдера Profile, к которому мог бы получить объект Content, и который мог бы каким-то образом получить экземпляр искомого профиля.

Это предпочтет композицию, которую вы ищете, отношениям родитель / ребенок.

Опять же, размышляя вслух, но я бы сделал так, чтобы объект контента имел зависимость типа IProfileProvider, и я бы вставил этого провайдера в объект контента, когда это необходимо. Это позволило бы мне составить тип контента с типом профиля, при этом явно не имея отношения родитель / потомок