 |
|
Архітектура «Модель - Представлення - Контроллер» і Android
Ймовірно, ви помітили, що об'єкти на мал. 2.4 розділені на три області: «Модель», «Контроллер» і «Представлення». Додатки Android будуються на базі архітектури, що називається «Модель-представлення-контроллер», або скорочено MVC(Model - View - Controller). Згідно з канонами MVC, кожен об'єкт додатка має бути об'єктом моделі, об'єктом представлення або об'єктом контроллера.
Об'єкт моделі містить ці застосування і «бізнес-логіку». Класи моделі зазвичай проектуються для моделювання сутностей, з якими має справу додаток, — користувач, продукт в магазині, фотографія на сервері, питання «та ні» і т. д. Об'єкти моделі нічого не знають про призначений для користувача інтерфейс; їх єдиною метою є зберігання і управління даними.
У додатках Android класи моделей зазвичай створюються розробником для конкретного завдання. Усі об'єкти моделі у вашому застосуванні складають його
рівень моделі.
Рівень моделі GeoQuiz складається з класу TrueFalse.
Об'єкти представлень уміють відображати себе на екрані і реагувати на введення користувача — наприклад, торкання. Просте правило: якщо ви бачите щось на екрані — значить, це представлення.
Android надає широкий набір класів представлень, що настроюються. Розробник також може створювати власні класи представлень. Об'єкти представлення в додатку утворюють рівень представлення.
У GeoQuiz рівень представлення складається з віджетів, заповнених по вмісту файлу activity _ quiz.xml.
Об'єкти контроллерів зв'язують об'єкти представлення і моделі; вони містять «логіку додатка». Контроллери реагують на різні події
що ініціюються об'єктами представлень, і управляють потоками даних між об'єктами моделі і рівнем представлення.
У Android контроллер зазвичай представляється субкласом Activity, Fragment або Service.
Рівень контроллера GeoQuiz нині складається тільки з класу
QuizActivity.
На мал. 2.5 показана передача управління між об'єктами у відповідь на призначену для користувача подію — таке, як натиснення кнопки. Зверніть увагу: об'єкти моделі і представлень не взаємодіють один з одним безпосередньо; у будь-якій взаємодії беруть участь «посередники» — контроллери, одержуючі повідомлення від одних об'єктів і передавальні інструкції іншим.
Мал. 2.5. Взаємодії MVC при отриманні введення від користувача
Переваги MVC
Додаток може обростати функціональністю до тих пір, поки не стане занадто складним для розуміння. Розділення коду на класи спрощує проектування і розуміння додатка в цілому; розробник мислить в контексті класів, а не окремих змінних і методів.
Аналогічним чином розділення класів на рівні моделі, представлення і контроллера спрощує проектування і розуміння додатка; ви можете мислити в контексті рівнів, а не окремих класів.
GeoQuiz не є складним застосуванням, але переваги розділення рівнів проявляються і тут. Незабаром ми оновимо рівень представлення GeoQuiz і додамо в нього кнопку Next. При цьому нам абсолютно не треба пам'ятати про тільки що створений клас TrueFalse.
MVC також спрощує повторне використання класів. Клас з обмеженими обов'язками краще підходить для повторного використання, ніж клас, який намагається займатися усім відразу.
Наприклад, клас моделі TrueFalse нічого не знає про віджетах, використовуваних для виведення питання «так/ні». Це спрощує використання TrueFalse в додатку для різних цілей. Наприклад, якщо потрібно буде вивести повний список усіх питань, ви можете використати той же об'єкт, який використовується для виведення усього одного питання.