Представлені результати дослідження основних архітектурних шаблонів (Model View Controller ( MVC ) І View Interactor Presenter Entity Router ( VIPER )), Що використовуються при проектуванні додатків для мобільної платформи iOS. Виявлено їх функціональні особливості, переваги і недоліки. Висвітлено сфери їх застосування для вибору оптимальної стратегії при розробці корпоративних додатків.

Анотація наукової статті з комп'ютерних та інформаційних наук, автор наукової роботи - Спірінцев В.В., Шитик Н.А.


THE ANALYSIS OF MODERN ARCHITECTURAL PATTERNS OF THE APPLICATIONS USED FOR PLANNING IS IN ENVIRONMENT OF IOS

The results of research of the basic architectural templates (Model View Controller ( MVC ) And View Interactor Presenter Entity Router ( VIPER )) Used for planning of appendixes for the mobile platform of iOS are presented. Their functional features, advantages and defects, are educed. The spheres of their application are lighted up for the choice of optimal strategy at development of corporate applications.


Область наук:

  • Комп'ютер та інформатика

  • Рік видавництва: 2016


    Журнал: Вісник Херсонського національного технічного університету


    Наукова стаття на тему 'АНАЛІЗ СУЧАСНИХ АРХІТЕКТУРНИХ ШАБЛОНІВ, ВИКОРИСТОВУЮТЬСЯ ПРИ ПРОЕКТУВАННІ ДОДАТКІВ В СЕРЕДОВИЩІ IOS'

    Текст наукової роботи на тему «АНАЛІЗ СУЧАСНИХ АРХІТЕКТУРНИХ ШАБЛОНІВ, ВИКОРИСТОВУЮТЬСЯ ПРИ ПРОЕКТУВАННІ ДОДАТКІВ В СЕРЕДОВИЩІ IOS»

    ?УДК 004.6

    ВВ. СПІРІНЦЕВ, НА. шитика

    Дніпропетровський національний університет ім. Олеся Гончара

    АНАЛІЗ СУЧАСНИХ АРХІТЕКТУРНИХ ШАБЛОНІВ, ВИКОРИСТОВУЮТЬСЯ ПРИ ПРОЕКТУВАННІ ДОДАТКІВ В СЕРЕДОВИЩІ IOS

    Представлені результати дослідження основних архітектурних шаблонів (Model - View -Controller (MVC) і View - Interactor - Presenter - Entity - Router (VIPER)), що використовуються при проектуванні додатків для мобільної платформи iOS. Виявлено їх функціональні особливості, переваги і недоліки. Висвітлено сфери їх застосування для вибору оптимальної стратегії при розробці корпоративних додатків.

    Ключові слова: патерни, MVC, VIPER, діаграма класів.

    В.В. СП1Р1НЦЕВ, М.А. ШІТ1К

    Дншропетровській нацюнальній ушверсітет iM. Олеся Гончара

    АНАЛ1З СУЧАСНИХ АРХ1ТЕКТУРНІХ ШАБЛОН1В, ЩО Використовують ПРИ ПРОЕКТУВАНН1 ДОДАТК1В У СЕРЕДОВІЩ1 IOS

    Представлет результати до ^ дження основних архiтектурно шаблонiв (Model - View -Controller (MVC) i View - Interactor - Presenter - Entity - Router (VIPER)), что Використовують при проектуванш додатюв для мобтьноІ Платформи iOS. Виявлено iXнi функцюнальш особлівостi, Переваги та недолжен. Вісвiтлено СФЕРИ iхнього! Застосування для Вибори оптімальноi стратеги при розробц корпоративних додаттв.

    Ключовi слова: патерни, MVC, VIPER, дiаграма клаав.

    V.V. SPIRINTSEV, М.А. SHYTIK

    Dnepropetrovsk National University named after Oles Honchar

    THE ANALYSIS OF MODERN ARCHITECTURAL PATTERNS OF THE APPLICATIONS USED FOR

    PLANNING IS IN ENVIRONMENT OF IOS

    The results of research of the basic architectural templates (Model - View - Controller (MVC) and View -Interactor - Presenter - Entity - Router (VIPER)) used for planning of appendixes for the mobile platform of iOS are presented. Their functional features, advantages and defects, are educed. The spheres of their application are lighted up for the choice of optimal strategy at development of corporate applications.

    Keywords: patterns, MVC, VIPER, diagram of classes.

    Постановка проблеми

    Корпоративні додатки найчастіше мають справу з різнорідними даними необмеженого обсягу і бізнес-правилами, логіка яких ускладнена великою кількістю приватних випадків, в умовах відмінності бізнес-процесів і представлення даних. Крім того, бізнес-вимоги можуть змінюватися в часі, і система повинна бути адаптується до внесення змін. У більшості випадків, можуть бути вирішені в процесі розробки таких програм завдання є однотипними. У зв'язку з цим актуальними є дослідження в напрямку проектування і реалізації шаблонного рішення, яке одночасно має бути достатньо гнучким для реалізації унікального для кожної програми функціоналу. Шаблон (або патерн) проектування в розробці програмного забезпечення - повторимо архітектурна конструкція, що представляє собою рішення проблеми проектування в рамках деякого часто виникає контексту [1]. Суть проектування архітектури додатку -використовувати сучасні інструменти, підходи і технології для отримання максимальної вигоди, з урахуванням вимог і обмежень, які випливають з поставлених завдань. При цьому необхідно максимально враховувати сучасні тенденції та тенденції найближчого майбутнього для забезпечення максимального прибутку через масштабованість, гнучкість і обслуговування. В якості ознак ефективної архітектури виділяють: збалансований розподіл обов'язків між сутностями з жорсткими ролями; тестованого, простота використання і низька вартість обслуговування.

    Аналіз останніх досліджень

    Для зниження складності системи шляхом абстракції і розмежування повноважень класів використовують принципи SOLID (Single Responsibility Principle, Open-Closed Principle, Liscov Substitution Principle, Interface Segregation Principle і Dependency Inversion Principle). SOLID - це п'ять основних принципів об'єктно-орієнтованого програмування і проектування, призначених для підвищення ймовірності створення системи, яку буде легко підтримувати і розширювати протягом тривалого часу [2]. Для задоволення проектованої системи різними атрибутами якості

    застосовуються архітектурні шаблони. Найбільш популярним шаблоном побудови системи для платформи iOS є шаблон Model - View - Controller (MVC), адаптований під особливості реалізації стандартних фреймовков UIKit і Foundation [3] (такий підхід рекомендує використовувати Apple в своїх гайдлайни по розробці). Однак при розробці великих корпоративних додатків за допомогою шаблону MVC можна зіткнутися з такими проблемами, як зосередження коду в контролерах, ускладнення тестування, недостатня модульність, висока зв'язаність класів і т.д. В якості альтернативи MVC (особливо при використанні Swift в якості мови розробки) при проектуванні архітектури все частіше використовують шаблон View - Interactor - Presenter - Entity - Router (VIPER), який дозволяє уникнути перерахованих недоліків архітектури, однак при цьому набагато збільшується кількість класів, інтерфейсів , і як наслідок - коду в цілому [1, 4].

    Формулювання мети дослідження

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

    Основна частина

    При розробці корпоративних додатків для мобільних платформ одним з найпопулярніших є шаблон MVC. При використанні MVC кожен клас в додатку виконує одну з трьох ролей: модель, контролер або уявлення, при цьому шаблон визначає не тільки ролі, але і те, як об'єкти взаємодіють один з одним. Модель инкапсулирует дані, логіку і правила обробки даних. Так як об'єкти моделей представляють собою знання в конкретній предметній області, вони можуть бути перевикористати для вирішення подібних завдань. Об'єкти моделей не повинні мати знання про своєму поданні та зв'язку з призначеним для користувача інтерфейсом. Взаємодія користувачів з шаром уявлення, наслідком якого є створення або оновлення даних, обробляється контролером, який в свою чергу оновлює шар даних [4]. Після того, як модель отримує оновлення (наприклад, дані, отримані з мережі; повідомлення від гіроскопа і т.д.), вона сповіщає контролер, який оновлює відповідні подання. Моделі діляться на активні і пасивні: активні моделі зберігають логіку і алгоритми, пасивні - дані. При розробці програм за допомогою фреймворка Cocoa Touch, в ролі пасивних моделей зазвичай виступають спадкоємці базового класу NSObject. У разі, якщо моделі необхідно зберігати в базі даних, це можуть бути спадкоємці NSManagedObject (надані стандартною оболонкою для роботи з базами даних в iOS - CoreData) [5], або спадкоємці об'єктів зі сторонніх рішень - RLMObject з бібліотеки Realm, MTLModel з Mantle і т.д. Відповідальністю об'єктів уявлення є відображення даних для користувачів, реакція на призначені для користувача дії і передача повідомлень про них контролера. Фреймворк UIKit надає великий набір стандартних компонентів шару уявлення, а безпосередньо розробку користувальницького інтерфейсу можна робити як з коду, так і за допомогою інструменту xCode Interface Builder. Контролер виступає посередником між моделлю і представленням, а також може координувати завдання додатки і управляти життєвим циклом інших об'єктів. MVC став стандартом в сучасній розробці програмного забезпечення для мобільних платформ завдяки поділу коду на бізнес-логіку, управління процесом виконання завдань і відображення, що сприяє масштабованості і підтримувані [6].

    UlView UlViewController

    а'

    f \

    View Controller

    L J

    -Owns and updates-| --- Notifies ""

    View Life Cycle

    Мал. 1. Схема взаємодії компонентів архітектури MVC

    Однак при значному збільшенні функціоналу використання MVC породжує деякі проблеми. MVC не передбачає розбиття функціоналу програми на модулі (як приклад, частою ситуацією в розробці корпоративних додатків є існування Сінглтона NetworkClient, який виконує запити по авторизації, створення користувацького контенту, пошуку користувачів і т.д.). При істотному розростанні функціоналу кількість таких універсальних класів збільшується (сервіси, хелпери, моделі), що значно збільшує зв'язаність коду. Для наочності розглянемо схематичну діаграму класів реального корпоративного програми, побудовану за допомогою утиліти dependency-visualizer (кожне коло - це клас, стрілка між класами означає, що один з класів в своїй реалізації звертається до іншого). Додаток побудовано на базі архітектури MVC, але без поділу на модулі.

    Ф

    Мал. 2. Діаграма класів додатки, розробленого за допомогою MVC

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

    Одним з найголовніших класів в Cocoa Touch є UlViewController, який керує набором уявлень, взаємодією між ними і передачею оновлень від відповідних моделей. Так як об'єкти-спадкоємці UIViewController відповідають за весь екранний інтерфейс в момент часу, в них зосереджується весь код, який відповідає за отримання даних з різноманітних джерел (відповіді на мережеві запити; координати від сервісу геолокації; повідомлення від акселерометра і гіроскопа і т. д.), обробку отриманої інформації, підготовку до відображення і безпосередньо відображення. Такий підхід порушує принцип єдиної відповідальності, ускладнює тестування, створює додатковий поріг складності для розуміння новими членами команди.

    Ще одним недоліком MVC при розробці для iOS є відсутність явного виділення відповідальності для навігації. У мобільних додатках часто виникає необхідність здійснювати складні переходи між призначеними для користувача сценаріями, і, при проектуванні за допомогою шаблону MVC, код, який відповідає за навігацію (вибір того, на який екран відбудеться перехід, наповнення відповідного спадкоємця UIViewController, здійснення анімованого переходу) залишається в ViewController і додає ще одну відповідальність до вищеперелічених.

    Для вирішення зазначених проблем була запропонована архітектура VIPER, яка є розширенням MVC. Вона більш детально розділяє відповідальності між шарами і вносить поняття модульності. Шар View збігається в обох архітектур, Interactor є активною моделлю і переймає обов'язки Model і ViewController, Presenter - шар, який відповідає за підготовку даних до відображення і передачу для користувача подій до рівня Interactor (в MVC цими завданнями займався ViewController), Entity - пасивна модель, Router (часто також званий Wireframe) - шар, який відповідає за навігацію.

    Router

    UIKil independent mediator

    Manipulates data and use cases

    UlView and / Of UlViewController

    View

    Owns and sends user actions

    4 ----- Updates- - *

    Presenter

    Owns and asks Г "l

    for updates Interactor

    1 i i i 1 Knows aboul | i

    i i A

    Entity

    Мал. 3. Схема взаємодії компонентів архітектури VIPER

    Взаємодія між шарами відбувається через інтерфейси (у класу, що належить до будь-якого з VIPER-шарів крім Entity є два протоколи - введення і виведення), тому один VIPER-модуль містить як мінімум п'ять класів і вісім інтерфейсів. Велика кількість шаблонного коду є головним недоліком VIPER, з яким частково можна боротися за допомогою кодогенераціі. Однією з широко використовуваних утиліт для генерації Swift-коду є Generamba, розроблена iOS-командою компанії Rambler, яка створює порожній VIPER-модуль з усіма класами і інтерфейсами, додає його в файлову систему проекту і в файл проекту .pbxproj.

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

    // Шар Entity - пасивна модель struct TextInfo {

    var collectionsDescriptionText = "" var descriptionText = "" var productsText = ""

    }

    // Шар Interactor - відповідає за отримання та обробку даних з мережі і оповіщення шару Presenter про оновлення c допомогою протоколу InteractorOutput protocol InteractorInput: class {

    weak var output: HomeInteractorOutput! {Get set} func fetchHomeInfo ()

    }

    protocol InteractorOutput: class {

    func interactorDidFetchTextInfo (homeInfo: TextInfo) func interactorDidFetchImageInfo (homeInfo: ImageInfo) func interactorHomeInfoFetchDidFail (error: NSError) func interactorDidFetchFullInfo ()

    }

    class Interactor: InteractorInput {weak var output: InteractorOutput! private let apiClient: APIClient private var homeTextInfo = TextInfo () private var homeImageInfo = ImageInfo () // MARK: - InteractorInput func fetchHomeInfo () {

    let executor = Executor.mainThreadExecutor () var tasks = [Task] ()

    let textInfoQuery = Content.homeQuery ( "key", containedIn: let textInfoTask = textInfoQuery.findObjectsInBackground () if let homeTextInfo = task.result as? [Content] {self? .parseTextServerResponse (homeTextInfo)

    }

    }

    )

    tasks = [textInfoTask]

    let combineTask = Task (forCompletionOfAllTasks: tasks)

    combineTask.continueWith ({[weak self] task in self? .didFinishLoading (task.error)})

    }

    // MARK: Response handling

    private func parseTextServerResponse (textContent: [Content]) {

    if let index = textContent.indexOf ({$ 0.key == TextInfoKey}) {let collectionsTextInfo = textContent [index]

    homeTextInfo.collectionsDescriptionText = collectionsTextInfo.textValue!

    }

    output.interactorDidFetchTextInfo (homeTextInfo)

    }

    }

    // Шар Presenter - відповідає за користувальницький введення, запит інформації з шару Interactor і оновлення вистав protocol PresenterOutput: class {

    func homePresenterDidSelectMenu (presenter: Presenter) func homePresenterDidSelectCollections (presenter: Presenter)

    }

    class Presenter: ViewOutput, InteractorOutput {var interactor: InteractorInput! weak var output: PresenterOutput! weak var view: ViewInput private var homeInfoLoaded = false // MARK: ViewOutput func viewIsReady () {

    interactor.fetchHomeInfo ()

    }

    func viewDidSelectCollections () {

    output.homePresenterDidSelectCollections (self)

    }

    // MARK: HomeInteractorOutput

    func interactorDidFetchTextInfo (homeInfo: HomeTextInfo) {view.applyTextInfo (homeInfo)

    }

    func interactorDidFetchImageInfo (homeInfo: HomeImageInfo) {view.applyImageInfo (homeInfo)

    }

    }

    // Створюється модуль за допомогою builder-методу. Важливо зауважити, що в архітектурі MVC клас UIViewController ставився до шару Controller, а в VIPER - до шару View.

    private func presentHome (animated: Bool) {

    let viewController = StoryboardScene.Profile.instanciateViewController () modulePresenter = Presenter () modulePresenter.output = self

    [TextInfoKey, ImageKey]) {[weak self] task in

    let interactor = Interactor (container: session.container) modulePresenter.interactor = interactor interactor.output = modulePresenter modulePresenter.view = viewController viewController.output = modulePresenter

    navigationController.setViewControllers ([homeViewController], animated: animated)

    }

    При правильному розбитті функціоналу програми на модулі діаграма класів може виглядати наступним чином:

    • • • * »• * • * | *» •

    • »Л * •:

    •• •

    . * * *. • • * * |

    • * • *

    V-

    ^ *

    • • 9

    Мал. 4. Діаграма класів додатки, розробленого за допомогою VIPER

    Як видно з рис. 4, VIPER-додаток містить набір класів (які є ядром додатка) і набір модулів, кожен з яких є відокремленою групою класів. Модуль з'єднується з ядром за допомогою класів - ModuleBuilder. Таким чином, логіка додатка розподіляється по модулях, отже, зменшується зв'язаність функціоналу, спрощується додавання або видалення модулів.

    висновки

    В роботі розглянуті найбільш поширені архітектурні шаблони для мобільної платформи iOS: MVC і VIPER. Зазначені патерни реалізують поділ відповідальностей між класами, що забезпечує високу переіспользуемость і гнучкість коду. Однак, при масштабуванні додатки абстракцій MVC недостатньо для того, щоб розділити функціонал між класами і повністю дотримуватися принципів SOLID. Використання шаблону VIPER дозволяє вирішити це завдання. З іншого боку, VIPER передбачає велику кількість класів і шаблонного коду, тому використання його в невеликих проектах, або в проектах, де немає перевикористання коду, є надмірною.

    перспективи досліджень

    Більшість мобільних додатків є Create - Read - Update - Delete (CRUD) клієнти, розроблені для вирішення повсякденних завдань: замовлення товарів і послуг, обмін графічними і текстовими даними, новинна агрегація і т.д. У більшості випадків, можуть бути вирішені в процесі розробки таких програм завдання є однотипними. У зв'язку з цим актуальними є дослідження в напрямку проектування і реалізації шаблонного рішення. Вибір правильної масштабируемой архітектури забезпечує якість програмного продукту, а рішення цього завдання дозволяє значно скоротити витрати на розробку додатків з таким функціоналом і збільшити їх стабільність за рахунок тестування шаблону в багатьох продуктах.

    Список використаної літератури

    1. Гамма Е. Прийоми об'єктно-орієнтованого проектування. Патерни проектування / Е. Гамма, Р. Хелм, Р. Джонсон, Дж. Вліссідес: пров. з англ. - С.-Петербург: Пітер, 2016. - 368 с.

    2. Мартін Р. Швидка розробка програм. Принципи, приклади, практика / Р. Мартін, Дж. Ньюкирк, Р. Косс: пров. з англ. - М .: Вільямс, 2004 - 752 с.

    3. Neuburg M. iOS 9 Programming Fundamentals with Swift: Swift, Xcode, and Cocoa Basics / M. Neuburg-S .: O'Reilly Media, 2015. - 604 р.

    4. Фрімен Е. Паттерни проектування / Е. Фрімен, К. Сієрра, Б. Бейтс: пров. з англ. -С.-Петербург: Пітер, 2016. - 656 с.

    5. Zarra M. Core Data: Data Storage and Management for iOS, OS X, and iCloud [Text] / M. Zarra - N.-Y .: Pragmatic Bookshelf, 2013. - 43 c.

    6. Бек К. Шаблони реалізації корпоративних додатків: пров. з англ. / К. Бек. - М .: Вільямс, 2000. -224 с.


    Ключові слова: патерни /PATTERNS /MVC /VIPER /ДІАГРАМА КЛАСІВ /DIAGRAM OF CLASSES

    Завантажити оригінал статті:

    Завантажити