документ db - денормализованные ссылки - лучшие практики

Question

Йо - это не проблема ravendb как таковая - это другой вопрос дизайна относящиеся к документам dbs в целом.

Так что я довольно часто использовал DenormalizedReference, и он имеет мне пришло в голову, что во многих местах это делает DDD довольно тяжелым.

Итак, скажем, например, у меня есть объект с дочерней коллекцией:

 List<DenormalizedReference<SomeType>>

Эта дочерняя коллекция создается, когда для экземпляра родителя перегруженный конструктор, принимающий List<SomeOtherType>

сейчас - в ctor я хотел бы создать этот список из SomeOtherType коллекция передается в - это означает, что мне нужно будет создать новый SomeType для каждого SomeOtherType.

Не передавая DocumentSession в мой домен - что я не собираюсь сделать - это не будет работать, потому что, когда родительский AR сохраняется, мы потерять свойства каждого дочернего объекта, кроме Id и Name

Как все остальные справляются с этим?

Answer 1

Вы не можете этого сделать. Или, скорее, вы не должны этого делать.

Есть несколько способов решить эту проблему, обычно используя статический шлюз для получения сеанса, но проблема в том, что этот подход создает отложенную загруженную коллекцию со всеми проблемами, которые возникают.

RavenDB был специально разработан, чтобы избежать подобных проблем. И вы можете включать элементы, чтобы избежать возврата на сервер, но вам не следует пытаться прозрачно переходить между идентификаторами и типами.