Лекция 9. Модель MVVM

Архитектура — это то, как вы структурируете код и файлы Android. Очень важно сделать ваш проект масштабируемым и поддерживать его. Разработчики тратят больше времени на поддержку проекта, чем на его создание, поэтому архитектура должна быть чистой и простой в обслуживании. Обычно на создание проекта с нуля требуются месяцы, но с годами в него добавляются различные дополнения в виде исправлений ошибок и новых функций в зависимости от требований.

MVC — это шаблон программирования, который позволяет разделить логику приложения на три части:

• Model (модель). Получает данные от контроллера, выполняет необходимые операции и передаёт их в вид.

• View (вид или представление). Получает данные от модели и выводит их для пользователя.

• Controller (контроллер). Обрабатывает действия пользователя, проверяет полученные данные и передаёт их модели.

Лучше всего понять концепцию MVC можно на реальном примере — ресторане с фастфудом. В нём посетители (пользователи) подходят к кассиру (одновременно вид и контроллер), видят меню и заказывают какое-нибудь блюдо.

Кассир проверяет, всё ли в порядке с заказом, и после оплаты передаёт нужные данные повару (модель). Повар готовит заказанное блюдо, хотя понятия не имеет о том, как выглядит посетитель, оплатил ли он заказ и так далее.

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

Если же говорить о приложениях, то компоненты будут следующие:

• Вид — интерфейс.

• Контроллер — обработчик событий, инициируемых пользователем (нажатие на кнопку, переход по ссылке, отправка формы).

• Модель — метод, который запускается обработчиком и выполняет все основные операции (получение записей из базы данных, проведение вычислений).

Стоит также отметить, что реализация паттерна MVC может отличаться в зависимости от задачи. Например, в веб-разработке модель и вид взаимодействуют друг с другом через контроллер (как в примере с рестораном), а в приложениях модель может сама уведомлять вид, что нужно что-то изменить.

Этот паттерн разработки нужен для того, чтобы разделить логические части приложения и создавать их отдельно друг от друга. То есть писать независимые блоки кода, которые можно как угодно менять, не затрагивая другие.

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

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

MVP — это паттерн программирования графических интерфейсов. В нём приложение делится на три компонента:

• Model (Модель) работает с данными, проводит вычисления и руководит всеми бизнес-процессами.

• View (Вид или представление) показывает пользователю интерфейс и данные из модели.

• Presenter (Представитель) служит прослойкой между моделью и видом.

Как и другие подобные паттерны (MVC, MVVM), MVP позволяет ускорить разработку и разделить ответственность разных специалистов; приложение удобнее тестировать и поддерживать.

Чаще всего его используют разработчики мобильных приложений, однако он гораздо популярнее, чем может показаться. Дело в том, что этот паттерн активно применяется в вебе, хотя там его и называют MVC:

На схеме выше видно, что приложение, созданное по принципам MVP, работает с помощью связи модели, вида и представителя. Происходит это так:

1. Вид строит интерфейс и добавляет в него данные из модели.

2. Пользователь видит информацию и взаимодействует с интерфейсом.

3. Вид перехватывает события и передаёт (делегирует) их представителю.

4. Представитель обрабатывает данные (не всегда) и передаёт их модели.

5. Модель выполняет какие-то операции и обновляется (меняет те или иные свойства).

6. Представитель получает обновлённую модель и передаёт её виду.

7. Вид строит интерфейс с новыми данными.

Основное отличие MVP и MVC в том, что в MVC обновлённая модель сама говорит виду, что нужно показать другие данные. Если же этого не происходит и приложению нужен посредник в виде представителя, то паттерн стоит называть MVP.

Всё это можно сравнить с работой издательства:

1. Автор готовит текст (модель).

2. Текст получает издатель (представитель).

3. Если с текстом всё в порядке, издатель передаёт его в отдел вёрстки (вид).

4. Верстальщики готовят книгу, которую начинают продавать читателям (пользователи).

5. Если пользователи как-то реагируют на книгу, например, пишут письма в издательство, то работа может начаться заново. Допустим, кто-то может заметить в книге неточность, тогда издатель передаст информацию автору, автор её обновит и так далее.

Конечно, это не точный алгоритм работы издательства, но для иллюстрации принципов MVP его достаточно.

MVC — это архитектура Android по умолчанию, где представление — это файлы макета xml, а контроллер — класс Activity. В MVVM файлы активности и xml рассматриваются как представления, а класс Viewmodel состоит из всей вашей бизнес-логики. Нет никакой связи между пользовательским интерфейсом приложения и бизнес-логикой.

В MVP ведущий знает о представлении, а представление знает о докладчике. Они взаимодействуют друг с другом через интерфейс. В MVVM только представление знает о модели представления. Модель представления не имеет представления о представлении.

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

Самый важный принцип, которому нужно следовать, — это разделение задач, т. е. ваша бизнес-логика, пользовательский интерфейс и модели данных должны находиться в разных местах. Другим является разделение кода: каждый фрагмент кода должен действовать как черный ящик, чтобы изменение чего-либо в классе не повлияло на другую часть вашей кодовой базы.

При работе с данными мы нередко сталкиваемся с проблемой их сохранения. В Xamarin Forms есть различные способы сохранения данных в зависимости от выбранного типа хранилища. Можно выделить четыре типа хранилища данных:

• Коллекция Properites в классе Application, которая предназначена для хранения каких-то временных данных

• Настройки (Preferences) операционной системы для хранения каких-то атомарных данных типа int или string

• Файлы в файловой системе

• Базы данных

Паттерн MVVM (Model - View - ViewModel) основывается на разделении функциональной части приложения на три ключевых компонента:

• View - представление или пользовательский интерфейс

• Model - модель или данные, которые используются в приложении

• ViewModel - промежуточный слой между представлением и данными, который обеспечивает их взаимодействие

Преимуществом использования данного паттерна является меньшая связанность между компонентами и разделение ответственности между ними. То есть Model отвечает за данные, View отвечает за графический интерфейс, а ViewModel - за логику приложения.

Легкость реализации паттерна MVVM в Xamarin Forms стала возможной благодаря ранее рассмотренному механизму привязки.

При разработке приложений в Xamarin.Forms пользовательский интерфейс обычно разрабатывается в XAML, а взаимодействие обеспечивается фоновыми кодами. Однако это вызывает проблемы с обслуживанием и тестированием, когда приложение растет и становится сложным. Вы можете избежать этих проблем, создавая проекты с использованием модели MVVM (Model-View-ViewModel).

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

Прежде всего, важно понять задачи компонентов и то, как они взаимодействуют друг с другом. Шаблон MVVM в Xamarin.Forms состоит из основных компонентов Model, View и ViewModel. Эти слои отделены друг от друга. Слой Model не знает слой ViewModel, а слой ViewModel не знает слой View. Таким образом, можно разрабатывать компоненты независимо друг от друга.

Модель – это невизуальные классы, которые содержат данные, которые будут использоваться в приложении. Класс модели не зависит от класса ViewModel. Примерами являются объекты передачи данных (DTO), простые старые объекты CLR (POCO).

Связывает данные между View и Model, выполняет команды и сообщает об изменениях, то есть действует как мост. ViewModel знает слой модели, но не слой View. ViewModel использует событие PropertyChanged при подключении данных и класс ObservableCollection для коллекций.

Представление – это слой, на котором представлено изображение приложения, то есть расположены элементы пользовательского интерфейса. В идеале, создавайте представления с помощью XAML. Таким образом, вы примените принцип Separation of Concerns. В приложениях Xamarin.Forms представление обычно является производным от класса Page или ContentView. Чтобы взаимодействовать с элементом представления в представлении, например, щелкнуть, выбрать, определите метод команды в классе ViewModel и подключите его к компоненту представления.

Класс ViewModel обычно привязывается к слою View декларативно и программно.

Декларативное связывание – более простой метод. Это декларативное связывание модели представления с BindingContext представления в XAML.

ContentPage ... xmlns:local="clr-namespace:eShop"

ContentPage.BindingContext

local:LoginViewModel /

/ContentPage.BindingContext

/ContentPage

При создании ContentPage автоматически создается экземпляр LoginViewModel и устанавливается в качестве BindingContext представления.

Его простота является преимуществом, но он связывается с конструктором по умолчанию класса ViewModel, то есть не имеет параметров.

Класс ViewModel связывается со свойством BindingContext в классе xaml.cs представления. С помощью этого метода можно подключить параметризованные методы конструктора класса ViewModel.

public LoginView()

{

InitializeComponent();

BindingContext = new LoginViewModel(navigationService);

}

Классы ViewModel и Model, доступные через View, должны реализовать интерфейс INotifyPropertyChanged. Таким образом, когда основные свойства класса ViewModel или Model изменяются, то компоненты в представлении также изменяются. Всегда вызывайте событие PropertyChanged, когда значение свойства изменяется и его значения используются другими свойствами. Также никогда не вызывайте событие PropertyChanged, если значение свойства не меняется.

В приведенном ниже примере BaseViewModel реализует интерфейс INotifyPropertyChanged. Метод OnPropertyChanged проверяет и сообщает об изменениях.

public class BaseViewModel : INotifyPropertyChanged

{

public event PropertyChangedEventHandler PropertyChanged;

public void OnPropertyChanged([CallerMemberName] string name = "")

{

PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));

}

}

• Принцип разделения ответственности (SoC): Модель MVVM позиционирует слои независимо друг от друга. Добавление новой модели не нарушает структуру проекта.

• Позволяет разрабатывать отдельный код на каждом слое. Таким образом, Front-end и Back-end разработчики могут легко сотрудничать.

• Простота сопровождения. Например, изменение, внесенное в класс Model, не влияет на представление.

• Повышает тестируемость. Поскольку визуальный интерфейс и код отделены друг от друга, их легче тестировать.

В отличие от преимуществ, данная модель также имеет некоторые недостатки.

• Увеличивается объем кода. Естественно, соединение слоев увеличивает объем кода.

• Увеличивается потребление памяти.

Подводя итоги, мы рассмотрели структуру и слои модели MVVM, затем соединительные слои, и, наконец, преимущества и недостатки. Следовательно, использование модели в проектах Xamarin.Forms облегчает сопровождение, тестирование и устойчивость. Более того, это значительно снижает сложность кода.

Пример из лабораторной работы:

Рассмотрим простейший пример. Определим класс данных или модели Phone.

Также добавим в проект класс, который назовем PhoneViewModel.

Это и будет компонент ViewModel, который связывает данные и визуальный интерфейс. По большому счету она представляет обертку над классом Phone, определяя все те же свойства. Для упрощения задачи сам объект Phone создается в конструкторе, хотя в реальности там могла бы быть более сложная логика, например, по получению объекта из базы данных.

Важно, что данный класс реализует интерфейс INotifyPropertyChanged, что позволяет уведомлять систему об изменении его свойств с помощью события PropertyChanged.

Отдельно создается визуальная часть. На главной странице MainPage.xaml определяется некое содержимое, где определена привязка к свойству ViewModel.

А в конструкторе страницы в файле кода c# прописана в качестве контекста данных для страницы определенная ранее ViewModel.

И при запуске приложение выведет нам все данные о viewmodel, переданной во view.

При использовании паттерна в качестве представления обычно выступает страница, и, как правило, одно представление (одна страница) связана с одной моделью представления (ViewModel). При этом одну и ту же VıewModel могут использовать несколько представлений.

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