Какой смысл иметь модели в WPF?

Ответ 1

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

• Класс Employee (Модель)
• EmployeeManagementViewModel, чтобы подготовить и представить список сотрудников и управлять изменениями состояния для вашего представления (например, может содержать SelectedEmployee, текст фильтра поиска и т.д.), который будет использоваться вашим EmployeeManagementView
• Список сотрудников (которые будут жить в вашем EmployeeManagementViewModel)

Скорее всего, у вас уже будет класс Employee. В этом случае вам просто нужно показать эту модель в EmployeeManagementViewModel как ObservableCollection сотрудников.

Если у вас не уже есть класс Employee, вы можете создать EmployeeViewModel и добавить свои свойства Employee, например, FirstName, LastName и т.д.

Технически это будет работать, но концептуально это беспокоит меня, потому что EmployeeViewModel не сотрудник ( он содержит сотрудника). Если вы абстрагируете реальность, тогда план работника не должен включать свойства или методы, которые будут использоваться в представлении. Для меня Employee должен быть POCO, который мог бы реализовать INotifyPropertyChanged и не более того. Вы отделяете состояние View от самой модели. Наличие сотрудника POCO упрощает UnitTest, создает макет сотрудников, сопоставляет его с таблицей базы данных через ORM и т.д.

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

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

Ответ 2

Модель может быть автоматически сгенерирована (Entity Framework) или вообще не может быть конкретным классом (подумайте о DataTable).

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

Ответ 3

Прежде всего, даже в MVVM вы можете открыть свою модель непосредственно в виртуальной машине и связать ее с моделью. {Binding MyModel.MyModelsProperty} где DataContext = ViewModel таким образом вам не обязательно обязательно обертывать все, если только это не ваш стиль.

ViewModel и Model имеют разные обязанности. Например, рассмотрите проектирование файлового проводника с древовидным представлением папок. Каждый node в древовидном представлении представляет собой каталог/папку. Каталоги являются моделями, и у них есть свойства, связанные с файловой системой. ViewModel может обертывать или раскрывать эти свойства для отображаемых узлов TreeView (например, имя каталога), но также добавляет дополнительную информацию, такую ​​как "IsEditing" и "IsExpanded", чтобы определить состояние, в котором находится node.

Ответ 4

Вы просто говорите об одном шаблоне в MVVM, на самом деле их больше.

В Stateful viewmodel вы фактически не делегируете вещи в Модели, сама модель Viewmodel сохраняет свое состояние, так что, как вы сказали в этом шаблоне, вы можете почти игнорируют модель, поскольку вы можете иметь состояние в самой VM.

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

В режиме просмотра без статусов вы делегируете вызовы модели, о чем вы, вероятно, имеете в виду.

Обратите внимание, что вы не обязательно реализуете INotifyPropertyChanged в Model. Просто реализовать его в VM прекрасно, если вы не изменяете свойства непосредственно в модели.

Итак, зачем нам нужны VM и Model? VM предназначена для поддержки вида, например, предоставления команд и т.д., А модель - просто сохранить абстракцию части данных.

Ответ 5

Модель - это только данные приложения низкого уровня.

Модель просмотра более конкретна.

• Это похоже на окно, в котором используются данные с учетом.
• Он также дополняет модель с деталями, необходимыми для представления. Хорошим примером является разбиение на страницы.
• Модель может иметь более одной модели представления. Эти модели представлений будут предлагать различные аспекты данных.
• Вы можете создать mashup различных источников данных. Модель взгляда четко охарактеризовала используемые модели.

Это означает, что между моделями и моделями просмотров нет отношения 1:1.

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

Ответ 6

В моем опыте, когда вы просто используете модели Domain как ViewModel (как свойство виртуальной машины), вы получаете много ключей, которые требуют, чтобы вы либо получили текстовое значение, либо хранилище в другом месте, либо добавили свойство VM в любом случае. В вашем представлении обычно больше информации, чем только одна модель домена (например, связанные объекты, отображаемые значения, значения статуса текста и т.д.), То, что модель домена не требует и в конечном итоге будет ее взвешивать. Модель представления посвящена потребностям представления, она кодирует представление "Простой и не сложный".

Ответ 7

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

В зависимости от проблем concurrency класс может быть статическим или инстанционным. Если вы можете отделить поведение достаточно, вы можете "разделить" классы DAL на отдельную модель для каждой модели представления, но дублированный код может стать проблемой.

Ответ 8

Википедия: MVVM

Модель: как и в классическом шаблоне MVC, модель относится к (а) модели домена, которая представляет реальный контент состояния (объектно-ориентированный подход), или (б) уровень доступа к данным, который представляет этот контент ( ориентированный на данные подход).

Ваш ViewModel не заменяет ваш домен Model. Он действует как intermidiate между вашим представлением и моделью, включая команды, привязывает коллекции к вашему представлению, проверку и т.д.

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