Как правильно разделить Entity Framework ContextObject между ViewModels? - PullRequest
Новая
       1

Как правильно разделить Entity Framework ContextObject между ViewModels?

3 голосов
/ 03 декабря 2011

Я новичок в WPF / MVVM / Entity Framework, и одновременно нужно работать с множеством концепций. Я создаю приложение WPF только с одним основным представлением, которое разделено на две части: 1 UserControl для основного представления моих данных, другой userControl для подробного представления. Все данные хранятся в базе данных, созданной с помощью модели сущностей Entity Framework.

Пока мне удалось сделать то, что я хотел (я использую MVVM light): привязку данных, команды, eventToCommand ... Я использую следующую архитектуру в проекте 1 VS: 1 папка для Views, 1 для ViewModels и 1 для определения Entities ,

Я передаю данные от мастера к деталям userControl с помощью MVVM Light Messaging, и когда я пытаюсь обновить одну сущность, я обнаружил исключение, сообщающее, что я не могу обновить, потому что я пытаюсь обновить один объект, связанный с ObjectContext (объявленный в MasterViewModel) с одним объектом из другого (объявлено в DetailViewModel)

Как я могу поделиться EF ObjectContext между ViewModels? Я прочитал кое-что о репозиториях или UnitOfWork, но мне не удалось увидеть, как я могу использовать его в моем случае.

Вспомогательный вопрос: каков наилучший способ доступа к объектам с EF и n-уровневым приложением? Является ли хранилище ответом? Учитывая тот факт, что классы уже существуют, я должен иметь папку «Модель» в моей архитектуре решения?

1 Ответ

5 голосов
/ 04 декабря 2011

Ответ заключается в двух упомянутых вами шаблонах проектирования.

Репозиторий - это шаблон проектирования, который помогает вам создать единую точку доступа к вашим данным.Например, CustomerRepository, который имеет такие функции, как GetById(int customerId), Update(Customer customer), Delete(Customer customer) и Add(Customer customer) и, в зависимости от вашего особого подхода к реализации шаблона, другие более специфические функции для обработки данных, в которых участвует клиент.

В обычном приложении у вас будет пара репозиториев, которые предоставят вам доступ к различным типам данных.В бизнес-функции вы затем использовали бы некоторые из этих репозиториев для создания функциональности.

Затем возникает шаблон UnitOfWork, поскольку это помогает вам сгруппировать набор связанных операций.Единица работы отслеживает изменения, пока вы не сохраните их в базе данных в целом.(ObjectContext в EF является реализацией шаблона UoW)

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

Это означает, что вы должны использовать одно UoW для основного и подробного представления.

Эта хорошая статья, которая показывает основы того, как реализация репозитория иШаблоны UoW могут выглядеть так, как при использовании EF.

Здесь вы можете найти объяснение шаблона репозитория и здесь Единицы работы (эти ссылки оба изШаблоны корпоративных приложений, действительно хорошая книга, если вы хотите узнать больше)

...