Как EF работает в приложениях WPF / Silverlight?

Question

Я некоторое время пытался сосредоточиться на двух понятиях одновременно, изучая MVVM (и одна из самых сложных задач - выяснить, какую платформу использовать. Мы даже не знали, сколько там были до нескольких недель назад) а также я пытаюсь изучить Entity Framework 4.2.

Это приложение для WPF, которое мы собираемся написать.

Я получил книгу Джулии Лерман, и я также прохожу онлайн-курс обучения по EF, но одна вещь, которую я до сих пор не понимаю, и еще не видел ни одного примера, это как справиться с чем-то вроде интерфейс INotifyPropertyChanged с классами, созданными с помощью EF, независимо от того, используем мы MVVM или нет, работа с INotifyPropertyChanged имеет жизненно важное значение.

Итак, позвольте мне задать здесь простой вопрос:

Разрешаете ли вы EF создавать все классы доступа к данным, которые отражают все данные в вашей базе данных, а затем дублировать большую часть этого кода, чтобы я мог заставить его работать с INotifyPropertyChanged? Или есть какой-то другой способ сделать это?

Answer 1

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

Затем я нашел хитрость: если вы собираетесь использовать WCF, он автоматически реализует INPC.
Для коллекций просто перейдите в конфигурацию Service Reference и установите ее так, чтобы она давала ObservableCollection в качестве типа коллекции по умолчанию.

Вот и все, вы настроены на MVVM =)

Answer 2

Ранее я использовал Entity Framework в нескольких моих приложениях WPF. В первый раз я впервые использовал EF Database. Было довольно сложно получить модель именно так, как я хотел, и как только она заработала, мне пришлось пройтись и реализовать INotifyPropertyChanged на моих классах сущностей.

Недавно я начал использовать EntityFramework CodeFirst с 4.1, я обнаружил, что намного проще обрабатывать все вещи, измененные в свойствах. Я обычно создаю базовый класс с INotifyPropertyChanged, реализованным на нем, и наследую мои сущности от этого.

Что касается ViewModel, я также начал беспокоиться об этой платформе или этой платформе. Позже я решил просто свернуть свой. Несомненно, у фреймворков есть некоторые интересные возможности, но для обучения мне было гораздо проще войти в него, создав собственный класс ViewModelBase и унаследовав от него все мои ViewModel.

ViewModelBase обычно реализует INotifyPropertyChanged. Позже я создал класс монитора ViewModel, который будет иметь коллекцию ViewModel. Чтобы найти их, я дал ViewModelBase свойство FriendlyName, чтобы для каждого типа унаследованного ViewModel могло быть задано имя для него (мои типы, как правило, RecordMaintenanceViewModel, NavigationViewModel, ShellViewModel и т. Д.), И я обычно наследую мои используемые ViewModel, зависящие от вида, от те. Поэтому в ShipmentView в моей программе доставки ShipmentViewModel наследуется от CollectionViewModel, который наследуется от ViewModelBase. Таким образом, у меня есть функциональность, разделенная на отдельные разделы, позволяющие мне обрабатывать определенные сценарии.

Я обычно портирую свою базу ViewModel на каждый проект и часто беру свои средние ViewModels; хотя иногда мне приходится их воссоздавать.

Answer 3

Поскольку ViewModel создается с учетом потребностей View, только в очень простых случаях ViewModel и ваш Entity относятся к одному и тому же классу. Обычно у вас есть класс Entity и класс ViewModel.
INotifyPropertyChanged является только одной из причин этого. Есть и другие, такие как преобразования, проверка, значимые сообщения об ошибках, агрегация и т. Д.