Шаблон MVVM состоит из трех частей — Model, View и ViewModel. Большинство разработчиков с самого начала немного смущаются относительно того, что Model, View и ViewModel должны или не должны содержать, и каковы обязанности каждой части.
В этой главе мы изучим обязанности каждой части шаблона MVVM, чтобы вы могли четко понимать, к какому типу кода относится. MVVM — это действительно многоуровневая архитектура для клиентской стороны, как показано на следующем рисунке.
-
Уровень представления состоит из представлений.
-
Логическим слоем являются модели представления.
-
Уровень представления представляет собой комбинацию объектов модели.
-
Клиентские службы, которые производят и сохраняют их, либо направляют доступ в двухуровневом приложении, либо через вызовы служб, а затем к вашему приложению.
-
Службы клиента официально не являются частью шаблона MVVM, но они часто используются с MVVM для достижения дальнейшего разделения и предотвращения дублирования кода.
Уровень представления состоит из представлений.
Логическим слоем являются модели представления.
Уровень представления представляет собой комбинацию объектов модели.
Клиентские службы, которые производят и сохраняют их, либо направляют доступ в двухуровневом приложении, либо через вызовы служб, а затем к вашему приложению.
Службы клиента официально не являются частью шаблона MVVM, но они часто используются с MVVM для достижения дальнейшего разделения и предотвращения дублирования кода.
Обязанности модели
В общем, модель является самой простой для понимания. Это модель данных на стороне клиента, которая поддерживает представления в приложении.
-
Он состоит из объектов со свойствами и некоторых переменных для хранения данных в памяти.
-
Некоторые из этих свойств могут ссылаться на другие объекты модели и создавать граф объектов, который в целом является объектами модели.
-
Объекты модели должны вызывать уведомления об изменении свойств, что в WPF означает привязку данных.
-
Последняя ответственность — проверка, которая является необязательной, но вы можете встроить информацию проверки в объекты модели, используя функции проверки привязки данных WPF через такие интерфейсы, как INotifyDataErrorInfo / IDataErrorInfo
Он состоит из объектов со свойствами и некоторых переменных для хранения данных в памяти.
Некоторые из этих свойств могут ссылаться на другие объекты модели и создавать граф объектов, который в целом является объектами модели.
Объекты модели должны вызывать уведомления об изменении свойств, что в WPF означает привязку данных.
Последняя ответственность — проверка, которая является необязательной, но вы можете встроить информацию проверки в объекты модели, используя функции проверки привязки данных WPF через такие интерфейсы, как INotifyDataErrorInfo / IDataErrorInfo
Посмотреть обязанности
Основная цель и обязанности представлений состоит в том, чтобы определить структуру того, что пользователь видит на экране. Структура может содержать статические и динамические части.
Статические части — это иерархия XAML, которая определяет элементы управления и макет элементов управления, из которых состоит представление.
Динамическая часть похожа на анимацию или изменения состояния, которые определены как часть представления.
Основная цель MVVM состоит в том, что в представлении не должно быть никакого кода.
Невозможно, чтобы в поле зрения не было кода. По крайней мере, вам нужен конструктор и вызов для инициализации компонента.
Идея состоит в том, что код логики обработки событий, действий и манипуляций с данными не должен быть в коде позади в View.
Существуют также другие виды кода, которые должны идти в коде за любым кодом, для которого требуется ссылка на элемент пользовательского интерфейса, который является неотъемлемым представлением кода.
ViewModel является основной целью приложения MVVM. Основная ответственность ViewModel заключается в предоставлении данных для представления, чтобы представление могло выводить эти данные на экран.
Это также позволяет пользователю взаимодействовать с данными и изменять данные.
Другая ключевая обязанность ViewModel — инкапсулировать логику взаимодействия для представления, но это не означает, что вся логика приложения должна входить в ViewModel.
Он должен иметь возможность обрабатывать соответствующую последовательность вызовов, чтобы все происходило правильно в зависимости от пользователя или любых изменений в представлении.
ViewModel также должен управлять любой логикой навигации, например, решать, когда пора переходить к другому представлению.