Покладіть свій контролер подання на дієту з розробкою веб-сайту з кодом MVVM, комп’ютерними іграми

свій

  • Поділитися у Facebook
  • Твіт
  • Поділіться в Google+
  • Опублікувати на Tumblr
  • Закріпіть
  • Додати до кишені
  • Відправити лист

У своєму останньому дописі в цій серії я писав про шаблон Model-View-Controller та деякі його недоліки. Незважаючи на очевидні переваги, які MVC приносить розробці програмного забезпечення, він не відповідає великим або складним додаткам какао.

Однак це не новина. Протягом багатьох років з’явилося декілька архітектурних зразків, які спрямовані на недоліки шаблону Model-View-Controller. Можливо, ви про це чули MVP, Model-View-Presenter та МВВМ, Наприклад, Model-View-ViewModel. Ці моделі виглядають і відчувають себе схожими на шаблон Model-View-Controller, але вони також вирішують деякі проблеми, які представляє шаблон Model-View-Controller.

1. Чому Model-View-ViewModel

Я використовував шаблон Model-View-Controller роками, перш ніж випадково натрапив на модель Model-View-ViewModel Шаблон. Не дивно, що MVVM є нащадком спільноти какао, враховуючи те, що його витоки сягають Microsoft. Однак модель MVVM перенесена на Какао та адаптована до вимог та потреб лісів з какао, і нещодавно набула популярності у спільноті какао.

Найбільш привабливим є те, як MVVM відчуває себе оновленою версією шаблону Model-View-Controller. Це означає, що він не вимагає кардинальних змін у мисленні. Після того, як ви зрозумієте основи шаблону, його досить легко реалізувати, не складніше, ніж шаблон model-view-controller.

2. Посадіть View Controller на дієту

У попередньому дописі я писав, що контролери в типовому додатку Cocoa дещо відрізняються від контролерів, які Ренскауг визначив у вихідному шаблоні MVC. Наприклад, на iOS контролер подання керує видом. Ваша виключна відповідальність - заповнити представлення, яким він керує, та відповісти на взаємодію користувача. Однак це не єдина робота контролерів перегляду в більшості додатків iOS?

Шаблон MVVM вводить у суміш четвертий компонент, Показати модель, що допомагає перефокусувати контролер перегляду. Це робиться шляхом прийняття на себе деяких обов'язків контролера перегляду. Погляньте на наступну схему, щоб краще зрозуміти, як модель подання вписується у шаблон Model-View-ViewModel.

свій

Як видно з схеми, контролер перегляду більше не є власником моделі. Модель перегляду є власником моделі, і контролер перегляду запитує у моделі перегляду дані для відображення.

Це важлива відмінність від шаблону модель-вигляд-контролер. Контролер перегляду не має прямого доступу до моделі. Модель перегляду дає контролеру перегляду дані, які він повинен відображати у своєму поданні.

Зв'язок між View Controller та його поданням залишається незмінною. Це важливо, оскільки контролер подання може зосередитись на заповненні свого подання та обробці взаємодії користувача. Для цього був розроблений View Controller.

Результат досить драматичний. Контролер перегляду посаджений на дієту, і багато обов’язків перекладено на модель перегляду. Зрештою, більше немає контролера перегляду, який охоплює сотні чи навіть тисячі рядків коду.

3. Обов'язки візуальної моделі

Напевно, вам цікаво, як модель перегляду вписується в загальну картину. Які завдання візуальної моделі? Як стосунки з контролером перегляду? А як щодо моделі?

Діаграма, яку я показав вам раніше, дає нам деякі вказівки. Почнемо з моделі. Модель більше не належить контролеру перегляду. Модель подання є власником моделі та діє як проксі-сервер для контролера перегляду. Коли контролеру подання потрібен елемент даних зі своєї моделі подання, він запитує у своєї моделі вихідні дані та форматує його, щоб контролер подання міг негайно використовувати його у своєму поданні. Контролер перегляду не несе відповідальності за обробку та форматування даних.

Діаграма також показує, що модель належить моделі перегляду, а не контролеру перегляду. Слід також зазначити, що шаблон Model-View-ViewModel враховує тісний взаємозв'язок між контролером подання та його видом, що характерно для додатків Cocoa. Через це MVVM відчуває себе природним вибором для застосування в какао.

4. Приклад

Оскільки шаблон Model-View-ViewModel не входить до складу Cocoa, немає суворих правил для реалізації шаблону. На жаль, це заплутано багатьма розробниками. Щоб пояснити кілька речей, я хочу показати вам основний приклад програми, яка використовує шаблон MVVM. Ми створюємо дуже простий додаток, який отримує дані про погоду за заздалегідь визначеним місцем з API Dark Sky і показує користувачеві поточну температуру.

Крок 1: Налаштування проекту

Запустіть Xcode і створіть новий проект на основі Додаток для одного перегляду Шаблон. Для цього підручника я використовую Xcode 8 та Swift 3.

дієту

Назвіть проект МВВМ, і поставити мова до Швидко і Пристрої до iPhone.

подання

Крок 2: Створіть модель подання

У типовому додатку Cocoa, що виконує шаблон model-view-controller, контролер перегляду виконує мережевий запит. Ви можете використовувати менеджер для запиту мережі, але контролер перегляду все одно знатиме, звідки надходять дані про погоду. Що ще важливіше, він отримує необроблені дані і повинен відформатувати їх, перш ніж відображатись користувачеві. Це не той підхід, який ми використовуємо, приймаючи модель Model-View-ViewModel.

Давайте створимо модель подання. Створіть новий файл Swift, назвіть його WeatherViewViewModel.swift, та визначити клас під назвою WeatherViewViewModel .

свій

Ідея проста. Контролер перегляду запитує у моделі перегляду поточну температуру для визначеного місця. Оскільки модель подання надсилає мережевий запит до API Dark Sky, метод приймає блокування, що викликається, коли модель подання має дані для контролера перегляду. Ці дані можуть бути поточною температурою, але також можуть бути повідомленнями про помилку. Ось так виглядає метод StromTemperatur (завершення:) В моделі подання. Ми заповнимо деталі за кілька хвилин.

Ми оголошуємо псевдонім типу і визначаємо метод StromTemperature (Завершення:), який приймає закриття типу CurrentTemperatureCompletion .В

Це не складно реалізувати, якщо ви знайомі з мережею та API URLSession. Погляньте на наведений нижче код і зауважте, що я використовував API маркерів, щоб все було гарно і чисто.

Єдиний фрагмент коду, який я вам ще не показував, - це реалізація температури (методом:). У цьому методі ми виділяємо поточну температуру з реакції Темного Неба.

У виробничій програмі я б обрав більш надійне рішення для аналізу відповіді, наприклад B. ObjectMapper або Unbox.

Крок 3: Інтегруйте модель подання

Тепер ми можемо використовувати модель подання в контролері перегляду. Ми створюємо властивість для моделі подання, а також визначаємо три виходи для інтерфейсу користувача.

Зауважте, що контролеру перегляду належить модель подання. У цьому прикладі контролер подання також відповідає за створення екземпляра своєї моделі подання. Як правило, я вважаю за краще вводити модель подання в контролер перегляду, але давайте просто зробимо це поки.

У методі viewDidLoad () Controller view ми називаємо допоміжний метод fetchWeatherData () .

У fetchWeatherData () ми запитуємо модель подання про поточну температуру. Перш ніж ми запитуємо температуру, ми приховуємо ярлик та кнопку та показуємо індикатор активності. Після закриття ми переходимо до fetchWeatherData (Завершення:), ми оновлюємо користувальницький інтерфейс, заповнюючи мітку температури та приховуючи індикатор активності.

Кнопка пов'язана з дією fetchWeatherData (_:), в якій ми також викликаємо допоміжний метод fetchWeatherData (). Як бачите, допоміжний метод допомагає нам уникнути дублювання коду.

Крок 4: Створіть користувальницький інтерфейс

Заключною частиною головоломки є створення користувальницького інтерфейсу для прикладу програми. відчинено Материнська плата і додати мітку та кнопку у вертикальний вигляд стека. Індикатор активності додається у верхню частину подання стека, відцентрований вертикально та горизонтально.

контролер

Не забудьте підключити виходи та дію, яку ми визначили у класі ViewController!

Тепер побудуйте та запустіть програму, щоб спробувати. Пам’ятайте, що для роботи програми вам потрібен ключ API Dark Sky. Ви можете зареєструвати безкоштовний рахунок на веб-сайті Dark Sky.

5. Які переваги?

Незважаючи на те, що ми перенесли лише кілька незначних речей у модель подання, можливо, вам цікаво, чому це потрібно. Що ми виграли? Чому ви повинні додати цей додатковий шар складності?

Найбільш очевидна перевага полягає в тому, що контролер подання є більш струнким і більше зосередженим на управлінні своїм видом. Це основне завдання контролера подання: управління його видом.

Але є і більш тонка користь. Оскільки View Controller не відповідає за отримання даних про погоду з API Dark Sky, він не знає деталей цього завдання. Дані про погоду можуть надходити від іншої метеорологічної служби або кешованої відповіді. Контролер перегляду не повинен і не повинен знати.

Тестування також значно покращує. Відомо, що контролери огляду важко перевірити через їх тісний зв’язок із площиною огляду. Переміщуючи частину бізнес-логіки у модель подання, ми негайно покращуємо перевірочність проекту. Тестування моделей перегляду напрочуд легко, оскільки вони не мають посилання на рівень перегляду програми.

Висновок

Шаблон Model-View-ViewModel є основним досягненням у дизайні додатків для какао. Контролери перегляду не такі обширні, моделі перегляду легше збирати та тестувати, і це полегшує роботу з вашим проектом.

У цій короткій серії ми лише подряпали поверхню. Про шаблон Model-View-ViewModel можна написати ще багато чого. За ці роки це стало одним із моїх улюблених зразків, і тому я постійно про це говорю і пишу. Спробуйте і дайте мені знати, що ви думаєте!

Тим часом ви можете переглянути деякі інші наші публікації про розробку додатків Swift та iOS.