2015-09-10 2 views
2

Я все еще пытаюсь понять DDD. Скажем, у меня есть неизменный VO PresentationSlide. Поскольку он является неизменным, его можно легко разделить и использовать разными сущностями. Но что произойдет, если я попытаюсь сопоставить это с базой данных. В EntityFramework я мог бы моделировать PresentationSlide как ComplexType, что означает, что свойства общего PresentationSlide сопоставляются с таблицами, используя его. Это прекрасно, но слайд может быть довольно большим, и поэтому я теряю пространство, если он использовал/ссылку несколько раз.Удалить сиротские общие объекты ValueObjects?

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

Разве это не проблема? Есть ли решение? Должен ли я выполнять специальный журнал «Очистка осиротевших представлений-задач»?

+0

Вы всегда можете выполнять очистку на основе таких событий, как 'PresentationChanged', или вы можете выполнять периодические очистки. Тем не менее, иногда может быть слишком дорого использовать VO, хотя нет никакой реальной потребности в идентификации. Мне кажется естественным, что 'PresentationSlide' будет изменчивым. Как часто вы действительно делитесь «PresentationSlide» между презентациями или даже повторно используете один и тот же слайд в одном? – plalx

+0

Я кое-что не понимаю. Если ** shared ** 'PresentationSlide' означает, что когда пользователь создает новую' Презентацию', он может выбрать для добавления существующего 'PresentationSlide' в' Presentation' вместо добавления нового. Но тогда вы должны оставаться сиротой 'PresentationSlides' для будущих новых/модифицированных' Презентаций'. – jlvaquero

ответ

0

Прежде всего, вы должны подумать о владении и жизненном цикле PresentationSlide в вашей модели домена. Всегда следите за семантикой модели при выполнении оптимизации производительности или хранилища.

  • Я начал бы с дублирования каждого PresentationSlide в пределах его сущности. Это естественный способ сделать это, потому что это то, что вы делаете и в своей модели домена.

  • Включите метрику, позволяющую принять обоснованное решение по оптимизации хранилища. Например. пойдите с подходом дублирования и вычислите пространство, потраченное впустую из-за дубликатов через некоторое время в производстве.

  • Только если у вас действительно есть проблема, выполните оптимизацию хранилища. В противном случае вы стали жертвой Premature Optimization.

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

Смежные вопросы