EF4 ASP.NET - управление правками объектов между сообщениями HTTP и откатом

Question

Я борюсь со следующим вариантом использования:

Пользователь вносит изменения в существующий заказ.Порядок сложный - множество связанных «сущностей» (адреса, параметры публикации, поставщики, марки, модели, различные предметы и т. Д.).В нескольких сообщениях http.

Пользователь хочет отменить изменения.

-

У меня есть объект заказа, и, поскольку пользователь редактирует это, я делаю различные изменения вассоциации сущностей, например, изменение order.address, order.items.add (item) ...

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

Это должно быть довольно распространенной проблемой - это сводит менябез ума.Любая помощь очень ценится.

Ура!

Answer 1

Да, это довольно распространено для нас.В большинстве сценариев мы используем подход MVC.Даже без реальных проектов ASP .NET MVC мы используем аналогичную ViewModel с нашими представлениями / страницами / сценариями и т. Д., Где нет прямого / единичного сопоставления сущностей с бизнес-уровнем (другими словами, Business.Entities).Это очень похоже на DTO.

Всегда легко использовать Disconnected EF.Мы извлекаем данные и отбрасываем контекст, затем трансформируем сущности в ViewModels / DTO, если это необходимо.Когда вам нужно сохранить изменения, все, что вам нужно сделать, это создать новый контекст, найти последний экземпляр сущности, который внесет изменения.

Представления / Страницы / Контроллеры будут управлять этими ViewModels / DTO.Отслеживание измененного и удаленного контента может быть выполнено путем введения HistoryList<T> (вы можете расширить List<T> для реализации этого).

После того, как все сделано, используя Controller / Workflow / Component, вы можете наблюдать ViewModel / DTOи внесите необходимые изменения в свои сущности, используя новый контекст для извлечения и сохранения.

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

/ КП

Answer 2

У нас есть похожая проблема, когда мы строим сложный бизнес-объект с помощью многостраничного мастера.

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

Если этот видПодход не был подходящим, я подозреваю, что вы смотрите на какое-то отслеживание различий, как на уровне сущности, так и на уровне базы данных.Ни один из них не прост в реализации, работе или управлении в системе.Первый из них будет своего рода вычислением и хранением n изменений в сущностях и разработкой алгоритма для их отмены, последний зависит от вашей СУБД, но может включать в себя версионные строки или аналогичные.