Глобальный контекст платформы объекта в приложении WPF
Я посреди разработки приложения WPF, которое использует Платформу Объекта (.NET 3.5). Это получает доступ к объектам в нескольких местах повсюду. Я волнуюсь по поводу непротиворечивости всюду по приложению в отношении объектов. Я должен инстанцировать отдельные контексты в своих различных взглядах, или должен я (и хороший способ сделать это), инстанцируют единственный контекст, к которому можно получить доступ глобально?
Например, моя модель объекта имеет три раздела, Поставки (с дочерними пакетами и дальнейшим дочерним содержанием), Компании/Контакты (с дочерними адресами и телефонами), и дисковые спецификации. Поставки и EditShipment просматривают доступ DiskSpecs, и OptionsView справляется, DiskSpecs (Создайте, Редактирование, Удалите). Если я редактирую DiskSpec, у меня должно быть что-то в ShipmentsView для получения последних спецификаций, если я имею отдельное право контекстов?
Если безопасно иметь один общий контекст, от которого остальная часть приложения получает, это - объекты, то я предполагаю, что это - способ пойти. Если так, куда тот экземпляр был бы помещен? Я использую VB.NET, но я могу перевести из довольно хорошего C#. Любая справка ценилась бы.
Я просто не хочу одно из тех приложений, где пользователь должен поразить перезагрузку дюжину раз в различных частях приложения для получения новых данных.
Обновление:
Хорошо, таким образом, я изменил свое приложение следующим образом:
- Все контексты создаются в Использовании Блоков для избавления от них после того, как они больше не будут необходимы.
- При загрузке все объекты отсоединяются от контекста, прежде чем он будет расположен.
- Новое свойство в MainViewModel (ContextUpdated) генерирует событие, которое все другие ViewModels подписывают на который выполнения тот метод ViewModels RefreshEntities.
- После реализации этого я начал получать ошибки, говоря, что на объект может только сослаться один ChangeTracker за один раз. Так как я не мог выяснить, какой контекст все еще ссылался на объект (не должно быть никакое право контекста?) Я снял объект в качестве IEntityWithChangeTracker, и ни на что установил SetChangeTracker (Пустой указатель).
Это позволило к текущей проблеме: Когда я Аннулирую changeTracker на Объекте и затем присоединяю его к контексту, он проигрывает, он изменил состояние и не становится обновленным к базе данных. Однако, если я не аннулирую средство отслеживания изменения, я не могу присоединить. У меня есть свой собственный код отслеживания изменений, так, чтобы не была проблема.
Мой новый вопрос, как Вы, как предполагается, делаете это. Хороший запрос Объекта в качестве примера и объект сохраняют отрезанный код, имел бы большое значение, вызвал бы, я побеждаю голову в попытке получить то, что я когда-то думал, была простая транзакция для работы.
2 ответа
Глобальный статический контекст редко является правильным ответом. Подумайте, что произойдет, если база данных будет сброшена во время выполнения этого приложения - ваше SQL-соединение разорвется, и все последующие запросы, использующие статический контекст, завершатся ошибкой.
Порекомендуйте вам найти способ значительно сократить время жизни контекста вашей сущности - открыть его, поработать, избавиться от него ...
Что касается помещения ваших различных объектов в один и тот же EDMX, это почти безусловно, правильный ответ, если у них есть какие-либо отношения между объектами, которые вам понадобятся в одном EDMX.
Что касается перезагрузки - пользователь никогда не должен этого делать. За кулисами вы можете открыть новый контекст, перезагрузив текущую версию объекта из базы данных, применив изменения, внесенные в пользовательский интерфейс, и затем сохранив их обратно.
Возможно, вы захотите также посмотреть на отдельные объекты и остерегаться исключений оптимистичного параллелизма, когда вы пытаетесь сохранить изменения, и кто-то другой изменил тот же объект в базе данных.
Хороший вопрос, Кори. Большой палец вверх от меня.
Entity Framework дает вам свободу выбора - вы можете либо инстанцировать несколько контекстов, либо иметь только один, статический. Это будет хорошо работать в обоих случаях, и да, оба решения безопасны. Единственный ценный совет, который я могу вам дать: поэкспериментируйте с обоими, измерьте производительность, задержки и т.д. и выберите лучшее для вас. Это весело, поверьте мне :)
Если это будет действительно массивное приложение с тоннами одновременных соединений, я бы посоветовал использовать один статический контекст или один статический, основной контекст и несколько дополнительных только для поддержки основного. Но, как я уже писал несколькими строками выше - это зависит от ваших требований, какое решение лучше для вас.
Мне особенно понравилась эта часть вашего вопроса:
Я просто не хочу одно из тех приложений, где пользователь должен нажимать перезагрузку дюжину раз в разных частях приложения, чтобы получить новые данные.
WPF - это очень, очень мощный инструмент, и, по сути, времена, когда пользователям приходилось нажимать кнопки для обновления данных, ушли навсегда. WPF предоставляет вам действительно широкий спектр асинхронных, многопоточных инструментов, таких как класс Dispatcher или Background worker, чтобы аккуратно обновлять нужные данные в фоновом режиме. Это действительно здорово, потому что вам не только не нужно беспокоиться о нажатии различных кнопок, но и фоновые потоки не блокируют пользовательский интерфейс, поэтому данные обновляются прозрачно с точки зрения пользователя.
WPF вместе с Entity Framework действительно стоят усилий по изучению - пожалуйста, не стесняйтесь спрашивать, если у вас есть какие-либо дополнительные вопросы.