Глобальный контекст Entity Framework в приложении WPF

Question

Я нахожусь в процессе разработки приложения WPF, использующего Entity Framework (.NET 3.5). Он обращается к сущностям в нескольких местах повсюду. Меня беспокоит согласованность всей заявки в отношении сущностей. Должен ли я создавать отдельные контексты в своих разных представлениях или я должен (и это хороший способ сделать это) создавать единый контекст, к которому можно получить глобальный доступ?

Например, моя модель сущности состоит из трех разделов: отгрузки (с дочерними пакетами и дополнительным дочерним содержимым), компании / контакты (с дочерними адресами и телефонами) и спецификации дисков. Представления «Отгрузки» и «EditShipment» обращаются к DiskSpecs, а «Options» управляет DiskSpecs («Создать», «Редактировать», «Удалить»). Если я редактирую DiskSpec, у меня должно быть что-то в ShipmentsView для получения последних спецификаций, если у меня есть отдельные контексты, верно?

Если безопасно иметь один общий контекст, из которого остальная часть приложения извлекает свои объекты, тогда я думаю, что это путь. Если так, то где этот экземпляр будет помещен? Я использую VB.NET, но я могу перевести с C # довольно хорошо. Любая помощь будет оценена.

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

Обновление:

ОК, поэтому я изменил свое приложение следующим образом:

1. Все контексты создаются с помощью блоков, чтобы избавиться от них после того, как они больше не нужны.
2. При загрузке все объекты извлекаются из контекста до его удаления.
3. Новое свойство в MainViewModel (ContextUpdated) вызывает событие, на которое подписываются все другие ViewModel, для которого выполняется этот метод ViewModels RefreshEntities.
4. После реализации этого я начал получать сообщения о том, что на сущность может ссылаться только один ChangeTracker за раз. Поскольку я не мог выяснить, какой контекст все еще ссылается на сущность (не должно быть никакого контекста, верно?), Я привел объект как IEntityWithChangeTracker и установил в SetChangeTracker ничего (Null).

Это позволило решить текущую проблему: Когда я обнуляю changeTracker на сущности, а затем присоединяю его к контексту, он теряет свое измененное состояние и не обновляется в базе данных. Однако если я не обнуляю трекер изменений, я не могу присоединиться У меня есть свой собственный код отслеживания изменений, так что это не проблема.

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

Answer 1

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

Рекомендую вам найти способ сократить время жизни вашегоконтекст сущности - откройте его, сделайте некоторую работу, избавьтесь от него, ...

Если поместить разные объекты в один и тот же EDMX, это почти наверняка правильный ответ, если у них есть какие-либо отношения между объектами, которые вы 'Я хочу, чтобы они были в том же EDMX.

Что касается перезагрузки - пользователь никогда не должен будет этого делать.За кулисами вы можете открыть новый контекст, перезагрузив текущую версию объекта из базы данных, применив изменения, сделанные в пользовательском интерфейсе, и сохранив их обратно.

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

Answer 2

Хороший вопрос, Кори.Откажитесь от меня.

Entity Framework дает вам свободный выбор - вы можете создавать несколько контекстов или иметь только один статический.Это будет хорошо работать в обоих случаях, и да, оба решения безопасны.Единственный ценный совет, который я могу вам дать: экспериментируйте с обоими, измеряйте производительность, задержки и т. Д. И выбирайте лучший для вас.Это весело, поверьте мне :)

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

Мне особенно понравилась эта часть вашего вопроса:

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

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

WPF вместе с Entity Framework действительно стоят усилий для изучения - пожалуйста, не стесняйтесь спрашивать, есть ли у вас какие-либо дополнительные проблемы.