Здравствуйте!

В Domain-модели есть некая Сущность — что-то типа документа.

Пользователь командами из интерфейса вносит изменения в эту Сущность.

Есть необходимость одновременно работать и со старой версией Сущности, и с новой версией.
Как я понимаю, это обычная модель редактирования документа?

Подскажите пожалуйста, как строится такая Модель? В каком слое?
Измененная, но еще не сохраненная Сущность хранится также в Domain-слое?
Получается, что обе версии Сущности будут иметь одинаковый ID-шник?

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

Здравствуйте, zelenprog, Вы писали:

Z>Здравствуйте!

Z>В Domain-модели есть некая Сущность — что-то типа документа.

Z>Пользователь командами из интерфейса вносит изменения в эту Сущность.

Z>Есть необходимость одновременно работать и со старой версией Сущности, и с новой версией.
Z>Как я понимаю, это обычная модель редактирования документа?

Z>Подскажите пожалуйста, как строится такая Модель? В каком слое?
Z>Измененная, но еще не сохраненная Сущность хранится также в Domain-слое?
Z>Получается, что обе версии Сущности будут иметь одинаковый ID-шник?

Z>Пробовал искать в интернете — ничего не нашел
Z>Если можно, дайте плиз ссылку на описание чего-то похожего, чтобы можно было от чего-то оттолкнуться.

А если это REST-сервис и использовать put/p

atch метод? Сделать в слое Repository метод update?
Правда если использовать какой-то ORM я не очень понимаю как лучше организовать одновременнуую работу как со старой так и с новой сущностью,
потому что во-первых есть кеширование, во-вторых, после вызова set с новым значением для какой-то entity, полученной по id, откуда взять старую версию? Снова обращаться по
id?(не уверен что это удачное решение)

Z>Есть необходимость одновременно работать и со старой версией Сущности, и с новой версией.

Что конкретно подразумевается под "работать"?

Z>Измененная, но еще не сохраненная Сущность хранится также в Domain-слое?

Это "хранится" в контролах формы редактирования

По кнопке сохранить из значений контролов собирается команда, которая улетает в сервисы. Там создаётся новая версия документа.
Каждое сохраненное изменение — новая версия.
Есть список версий.
Из него можно поднять любую из предыдущих версий, посмотреть или отредактировать.
Последнее создаст новую версию документа.

Сущности, например, такие

record Document (long Id, string Title, ...)
record DocumentVersion(long Id, string DocumentId, int VersionNumber, byte[] Content, DateTime CreatedAt, ...)

Z>Если можно, дайте плиз ссылку на описание чего-то похожего...

Посмотри как в Google docs версионирование сделано.

A_L>Правда если использовать какой-то ORM я не очень понимаю как лучше организовать одновременнуую работу как со старой так и с новой сущностью,
A_L>потому что во-первых есть кеширование, во-вторых, после вызова set с новым значением для какой-то entity, полученной по id, откуда взять старую версию? Снова обращаться по
A_L>id?(не уверен что это удачное решение)

Нет, ORM-а нету.
Все делается "вручную":
— Сущности хранятся в обычной реляционной БД
— кеш Сущностей организован в памяти (в коллекции) также "вручную"

RD>Что конкретно подразумевается под "работать"?

Бизнес-логика по запросу пользовательского интерфейса должна выдать либо старую версию, либо новую версию Сущности.
Пользовательский интерфейс показывает разницу между ними в упрощенном виде.
И только когда пользователь явно даст команду типа "Зафиксировать", только тогда Бизнес-логика формирует окончательно новую версию, и заменяет старую версию на новую.


RD>Это "хранится" в контролах формы редактирования

В контролах хранятся изменения, еще не переданные на сервер.

RD>По кнопке сохранить из значений контролов собирается команда, которая улетает в сервисы. Там создаётся новая версия документа.
RD>Каждое сохраненное изменение — новая версия.
RD>Есть список версий.

А версии хранятся в самом "сервисе" (сервере, domain-слое).
Верно?

RD>Посмотри как в Google docs версионирование сделано.

Хотелось бы посмотреть не просто с точки зрения пользователя, а с точки зрения разработчика: то есть более-менее детальную диаграмму модели версионирования.

Z>Бизнес-логика по запросу пользовательского интерфейса должна выдать либо старую версию, либо новую версию Сущности.
Z>Пользовательский интерфейс показывает разницу между ними в упрощенном виде.
Z>И только когда пользователь явно даст команду типа "Зафиксировать", только тогда Бизнес-логика формирует окончательно новую версию, и заменяет старую версию на новую.

Ну и зачем что-то промежуточное "хранить" при такой постановке?

class DocumentsService { 
  public DocumentVersion GetLastVersion(long docId) {
  // Поднимаем из БД последнюю версию документа 
  }

  public DocumentVersion Save(SaveCommand cmd) {
  // Создаём новую версию, заполняем ее из command, сохраняем в БД
  // Это будет вызывать UI, когда пользователь подтвердит сохранение 
  }

  public DocumentDiff CalculateDiff(byte[] oldContent, byte[] newContent) {
  // Вычисляем изменения, отдаем клиенту, ничего не сохраняем в БД.
  // Это будет вызываться UI, чтобы показать изменения между текущей и новой версией
  }
}

Z>А версии хранятся в самом "сервисе" (сервере, domain-слое).
Z>Верно?

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