Использование самопроверяющихся сущностей в ASP.NET для нескольких постов

Question

У меня есть простое требование (так я думал ...!)

У меня есть модель, состоящая из Order, OrderLine, Product.

Я хочу создать Order и добавитьЛинии заказа (каждая Линия заказа связана с продуктом).Я создаю Заказ и добавляю новые Линии Заказа к нему.Между постами я сохраняю сущность Order в Session (или ViewState).Точно так же, как вы знаете, я добавил поддержку для двоичной сериализации, которая работает нормально.

Таким образом, связь такая: Order> OrderLine (s)> Product (s).

Возможно, вы уже догадались, чтопроблема в том, что когда я SaveChanges () я получаю обычное «AcceptChanges не может продолжаться, потому что значения ключа объекта конфликтуют с другим объектом в ObjectStateManager».ошибка.

Я ссылался на ряд статей в Интернете, но, похоже, ни одна из них не касается этого случая (где у меня есть отношения между более чем двумя организациями), например, http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx.

Это должно бытьочень распространенное требование, конечно?Есть ли кто-нибудь, кто делает то же самое с Entity Framework (и без использования DTO и т. Д.)?

Приветствия - помогите!:)

Ник

Answer 1

Я часто слышу это "НЕ ЕСТЬ", но почему бы и нет?У меня есть многоуровневое приложение с компонентами WinForms, WPF и ASP.Net, и я использую свои STE для всех уровней.В ASP просто убедитесь, что вы сохраняете свой STE обратно в Viewstate \ Sessionstate надлежащим образом между публикациями / изменениями, и ваш код должен работать нормально.

У меня есть сущности, у которых много уровней отношений без проблем, есть несколько примеров этогопотому что принципы одинаковы независимо от того, сколько уровней.Я рекомендую продолжать работу с STE, если у вас есть время / терпение, чтобы ваши сценарии соответствовали вашим потребностям.Теперь у меня есть надежная структура, основанная на STE, которую я использую во всех своих приложениях.

STE позволяют мне получать доступ к данным в SharePoint (.Net 3.5), когда приложение модели и управления фактически.Net 4.0, это одно из часто упускаемых преимуществ STE по сравнению с Entity Framework.

См. Самостоятельно отслеживаемые объекты: ApplyChanges и дублирующиеся объекты для получения помощи по вашей конкретной проблеме.

Answer 2

Это то, что я решил сделать ...

Используйте сгенерированные EF сущности и ассоциации (НЕ STEs - вы правы Ник), чтобы построить порядок. Всегда включайте иностранные ключи.

Установите для параметра MergeOption значение NO TRACKING, т. Е. Отключено.

Сохраняйте соответствующие объекты в сеансе между сообщениями / запросами страниц, пока пользователь формирует заказ.

Важно: при связывании дочерних сущностей (например, OrderLines) не связывайте существующие дочерние сущности через отношения, а используйте идентификатор FK. Поэтому не используйте OrderLine.Product = product, а используйте OrderLine.Product_Id = product.Id. Это устраняет проблемы, когда существует несколько сущностей в разных контекстах.

Когда заказ будет выполнен и готов к сохранению, добавьте в контекст и SaveChanges.

-

При редактировании существующего заказа ...

Установите для MergeOption значение NO TRACKING.

Сохранение соответствующих сущностей в SESSION между сообщениями / запросами страниц, пока пользователь редактирует заказ.

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

Когда изменения завершены и готовы к сохранению, присоедините их к контексту, обработайте изменения (задайте для ObjectState значение MODIFIED и т. Д.) И SaveChanges.

-

Создает мечту - недолговечный контекст (UOW) - нет View Model или DTO (просто используйте классы Entity) - нет сложного кода (отсоединение / присоединение графиков и т. Д.).

Примечание: не сохраняется в VIEWSTATE. Нужно разобраться в этом, так как я захочу перейти с InProc на SQL. Буду обновлять.

Возможно, я что-то упустил, но я потратил МНОГО времени на поиски возможных решений для этого.