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

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

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

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

--

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

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

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

Ваше здоровье!


asp.net entity-framework entity-framework-4
person gochid    schedule 27.07.2010    source источник
comment
Используете ли вы самоотслеживающие объекты? Если это так, вы можете сохранить их в состоянии просмотра, если вы знаете, что они не станут большими.   -  person Dan H    schedule 28.07.2010

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Colin Desmond    schedule 10.08.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

/KP

person Kosala Nuwan Perera    schedule 15.08.2010