Как сохранить только измененные части агрегата во время сохранения?

Я пытаюсь представить DDD в новом проекте. Во-первых, меня интересует реализация единицы работы и репозитория для агрегатов без помощи ORM. (Команда решила не использовать Entity Framework из-за его сложности.)

У меня есть один репозиторий на совокупный корень. Предположим, что совокупный корень равен User, он содержит объект Membership и объект-значение Address (остальные игнорируются для простоты).

Все доменные классы не зависят от сохранения, что означает, что они являются простыми классами C# и не имеют никакого метода, который принимает какой-либо параметр (например, его соответствующий репозиторий), связанный с сохранением.

Когда я загружаю экземпляр user из репозитория, я обновляю только поле user.Address. Я думаю о методе единицы работы, который выглядит так:

unit_of_work.Add(user);
....
unit_of_work.Commit();

Я пытаюсь сделать так, чтобы unit_of_work знал, какие свойства в user действительно изменились, и сохранял только их. Но как unit_of_work узнает, что изменено только Address поле, а не остальная часть User агрегата? В этом случае мне нужно, чтобы каждый дочерний объект/значение объекта сам отслеживал изменения. Но если я это сделаю, это противоречит моей первоначальной цели, заключающейся в том, что все доменные классы являются постоянными-агностиками.

У меня есть два неоптимальных решения, которые мне не очень нравятся:

  1. слепое обновление всей совокупности, игнорируя, какие части изменились, а какие нет.
  2. сделать глубокую копию всего агрегата, и после Commit я сравниваю исходный агрегат и его копию и отправляю только изменения.

person foresightyj    schedule 18.12.2015    source источник
comment
Отслеживание изменений — одна из причин, по которой готовые формы становятся немного сложными. Может быть, хотите переосмыслить решение не использовать его. Один не упомянутый подход заключается в том, чтобы объекты отправляли уведомление при внесении изменений и отслеживали уведомления. doctrine-orm. readthedocs.org/projects/doctrine-orm/en/latest/   -  person Cerad    schedule 18.12.2015
comment
@theDmi Спасибо, что указали на это. Ответ, который у вас есть на этот вопрос, касается моих опасений.   -  person foresightyj    schedule 19.12.2015
comment
@Cerad На самом деле мы планируем использовать Dapper, к которому мы все привыкли, микро-ORM, который в основном является помощником SQL, который не предлагает возможности единиц работы и шаблонов репозитория, таких как Entity Framework. Я сказал это, чтобы упростить свой вопрос. Шаблон уведомлений кажется хорошим, хотя мне нужно немного изменить классы моделей.   -  person foresightyj    schedule 19.12.2015