Сохранение объекта DDD без геттеров

Я думаю, что мне не хватает чего-то действительно очевидного, но есть много разногласий по объектам домена и их сохранению через репозиторий, поэтому трудно получить четкий ответ по этому поводу.

Если предположить, что

  • Я построил чистую модель предметной области, которая НЕ имеет НИКАКИХ зависимостей от каких-либо других сборок в моем решении, как утверждает DDD, только с одним чистым корневым агрегатом.

  • У меня есть репозиторий для конкретного домена, в котором сохраняется корневой агрегат, вызываемый уровнем обслуживания.

  • Внутри репозитория используется EF для сохранения объекта вместе с его дочерними элементами.

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

Параметры ??

  1. Внедрение зависимости в модель предметной области (запах DDD ??)

  2. Только геттеры (запах DDD ??)

Также существует обратная проблема с извлечением объектов из БД. Инициализация через конструктор кажется единственным вероятным кандидатом.


repository getter domain-driven-design
person csherriff    schedule 05.03.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

ORM может получить данные внутри объектов через отражение. Например, NHibernate имеет различные стратегии доступа к свойствам, которые позволяют отображаемым классам иметь только частные поля без геттеров или сеттеров. Я думаю, что у EF должны быть аналогичные объекты.

person eulerfx    schedule 05.03.2013
comment
Я, наверное, мог бы это сделать, но это немного странно - person csherriff; 05.03.2013
comment
Спасибо eulerfx .. После дальнейшего чтения я думаю, что идея общедоступного геттера / частного сеттера, вероятно, является лучшим вариантом здесь .. По крайней мере, пока я не разберусь, как справиться со всей этой проблемой незнания EF5. Честно говоря, я слишком сильно настаиваю на получении чистой реализации DDD ... Я думаю, что стоит подробно обдумать проблемы, хотя - person csherriff; 06.03.2013

arrow_upward
2
arrow_downward

Как заявил eulerfx: поскольку вы используете ORM, вы должны использовать то, что он предоставляет.

Я никогда не буду добровольно использовать ORM, поэтому мой опыт несколько ограничен, но, похоже, проблема в том, что ORM в той или иной форме проникает в объектную модель. В некоторых случаях это заставляет вас разрабатывать классы определенным образом.

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

У вас может быть какой-то объект состояния, который отображается / потребляется вашим объектом, и хотя намерение несколько яснее, оно просто устраняет проблему - но, вероятно, это лучше :).

Даже с источником событий события содержат состояние и должны быть применены к объекту, чтобы вернуть его в его последнее состояние, или вы можете использовать моментальный снимок, который точно такой же, как объект состояния.

Публичные геттеры и сеттеры в некоторой степени открыты для злоупотреблений, но это то, что есть.

person Eben Roux    schedule 05.03.2013
comment
Я счастлив использовать сгенерированные EF5 объекты для целей сохранения, поскольку они существуют только в моей сборке репозитория. Я предположил, что если DDD заявляет, что требуется чистый код сборки домена, то у них должно быть какое-то решение этой проблемы. Наименее инвазивный метод, кажется, просто вводит IRepository в мой корневой агрегат. - person csherriff; 05.03.2013