Наукова новизна одержаних результатів

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

Практичне значення отриманих результатів

Створення єдиного синтаксису мов програмування в процесі об’єднання функціональних можливостей, в якому, кожен подається своїм

 синтаксисом, створює універсальність у застосуванні.

Апробація результатів МВР

Результати досліджень по темі магістерської випускної роботи викладалися і обговорювалися на міжнародній науково-практичній конференції «Результати наукового розвитку – 2019».

Публікації

По темі магістерської випускної роботи опублікована теза [26].

Результат розробки

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

 

 

РОЗДІЛ 1

ПОСТАНОВКА ЗАДАЧІ

Теоретичні відомості

Фреймворк – це програмне середовище, яке призначене для підтримки розробки WEB систем, в тому числі WEB служб, WEB ресурсів і WEB API [6]. Web фреймворки надають стандартний спосіб створення і розгортання WEB систем в мережі інтернет. Web фреймворки націлені на автоматизацію часових витрат, пов'язаних із загальними діями, виконуваними в WEB розробці. Наприклад, багато WEB фреймворків надають бібліотеки для доступу до баз даних, управління сесіями, і вони часто сприяють повторному використанню коду. Хоча вони часто націлені на розробку динамічних WEB сайтів, вони також можуть бути застосовані і до статичних WEB сайтів.

Оскільки дизайн всесвітньої павутини не був по своїй природі динамічним, ранній гіпертекст складався з HTML коду, написаного вручну, який був опублікований на WEB серверах. Будь-які зміни опублікованих сторінок повинні бути виконані їх автором. У 1993 році був введений стандарт Common Gateway Interface (CGI – специфікація інтерфейсу для WEB серверів для виконання програм, які виконуються як консольні додатки, що працюють на сервері, який генерує WEB сторінки динамічно) для взаємодії зовнішніх систем з WEB серверами, щоб забезпечити динамічну WEB сторінку, яка відображатиме для користувача введення.

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

У 1995 році вперше з'явилися повністю інтегровані середовища розробки сервера і були представлені нові мови для WEB сайтів, такі як ColdFusion, PHP і Active Server Pages.

Хоча в переважній більшості мов для створення динамічних WEB сторінок є бібліотеки, які допомагають виконувати спільні завдання, WEB системам часто потрібні спеціальні бібліотеки для конкретних завдань, таких як створення HTML (наприклад, JavaServer Faces).

В кінці 1990-х років стали з'являтися фреймворки, які часто збирали безліч бібліотек, корисних для WEB розробки, в єдиний стек програмного забезпечення, який могли б використати WEB розробники. Приклади цього включають: ASP.NET, Java EE, WebObjects, web2py, OpenACS, Catalyst, Mojolicious, Ruby on Rails, Grails, Django, Zend Framework, Sails.js,  CakePHP і Symfony.

Багато фреймворків слідують архітектурному шаблону MVC, щоб відокремити модель даних за допомогою бізнес-правил від призначеного для користувача інтерфейсу. Як правило, це вважається хорошою практикою, так як він модулює код, сприяє повторному використанню коду і дозволяє застосовувати кілька інтерфейсів. У WEB системах це дозволяє представляти різні уявлення, такі як WEB сторінки.

У трирівневої організації WEB системи структуровані за трьома фізичним рівнями: клієнт, система і база даних. База даних зазвичай є СУБД. Система містить бізнес-логіку, працює на сервері і зв'язується з клієнтом по протоколу HTTP. Клієнт в WEB системах – це WEB браузер, який запускає HTML, згенерований прикладним рівнем.

Фреймворки створені для підтримки створення WEB систем на основі однієї мови програмування, починаючи від інструментів загального призначення, таких як, наприклад, Zend Framework і Ruby on Rails, які розширюють можливості конкретної мови, до програмованих пакетів на рідній мові, побудованих на основі конкретного призначення для WEB системи користувача, таких як системи управління контентом, деякі мобільні засоби розробки і деякі портальні інструменти.

Web платформи повинні функціонувати відповідно за архітектурними правилами браузерів і WEB протоколів, таких як HTTP, який не має стану. Web сторінки обслуговуються сервером і потім можуть бути змінені браузером за допомогою JavaScript. Будь який підхід має свої переваги і недоліки.

Зміни сторінки на стороні сервера зазвичай вимагають оновлення сторінки, але дозволяють використовувати будь-яку мову і використовувати більше обчислювальної потужності. Зміни на стороні клієнта дозволяють оновлювати сторінку невеликими порціями, які виглядають як статичні сторінки WEB системи, але обмежені JavaScript і запускаються в браузері користувача, який може мати обмежену обчислювальну потужність. Web системи, які інтенсивно використовують JavaScript, називаються односторінковими додатками і зазвичай використовують клієнтську WEB інфраструктуру JavaScript для організації коду.

Фреймворки зазвичай встановлюють потік управління програмою і дозволяють користувачеві фреймворка «підключатися» до цього потоку, виставляючи різні події [7]. Цей шаблон проектування «інверсія управління» вважається визначальним принципом структури і приносить користь коду, забезпечуючи загальний потік для команди, який кожен може налаштувати подібним чином. Наприклад, деякі популярні «мікрофрейми», такі як Sinatra Рубі (яка надихнула Express.js), допускають перехоплення «проміжного програмного забезпечення» до і після HTTP-запитів. Ці функції проміжного програмного забезпечення можуть бути будь-якими і дозволяють користувачеві визначати ведення журналу, аутентифікацію і управління сеансами, а також перенаправлення.

Web кешування – це кешування WEB документів з метою зменшення пропускної здатності використання серверного навантаження [2]. Web кеш зберігає копії документів, що проходять через нього. Наступні запити можуть бути задоволені з кешу, якщо дотримані певні умови. Деякі прикладні платформи надають механізми для кешування документів і обходу різних етапів підготовки сторінки, таких як доступ до бази даних або інтерпретація шаблонів.

Деякі WEB платформи поставляються з платформами аутентифікації і авторизації, які дозволяють серверу ідентифікувати користувачів та обмежують доступ до функцій на основі певних критеріїв. Drupal – один із прикладів, який надає доступ до сторінок на основі ролей і надає WEB інтерфейс для створення користувачів і призначення їм ролей.

Багато WEB фреймворків створюють єдиний API для серверної частини бази даних, дозволяючи WEB системами працювати з різними базами даних без змін коду і дозволяючи програмістам працювати з концепціями більш високого рівня [8]. Крім того, деякі об'єктно-орієнтовані структури містять інструменти відображення, щоб забезпечити об'єктно-реляційне відображення, яке відображає об'єкти в кортежі.

Деякі платформи мінімізують конфігурацію WEB систем за рахунок використання самоаналізу. Наприклад, багато фреймворків Java використовують Hibernate в якості рівня персистентності, який може генерувати схему бази даних під час виконання, здатну зберігати необхідну інформацію. Це дозволяє розробнику системи проектувати бізнес-об'єкти без необхідності явно визначати схему бази даних. Фреймворки, такі як Ruby on Rails, також можуть працювати в зворотному порядку, тобто визначати властивості об'єктів моделі під час виконання на основі схеми бази даних.

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

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

- забезпечити надійні одиниці роботи, які дозволяють коректно відновлюватися після збоїв і підтримувати узгодженість бази даних навіть у разі збою системи, коли виконання зупиняється (повністю або частково) і багато операцій над базою даних залишаються незавершеними з невідомим

статусом;

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

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

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

Скаффолдинг (з англ. «Scaffolding») – це метод, який підтримується деякими платформами модель-уявлення-контролер, в якому програміст може вказати, як можна використовувати базу даних програми [13]. Компілятор або структура використовує цю специфікацію, разом з попередньо визначеними шаблонами коду, щоб створити код, який система може використовувати для створення, читання, оновлення та видалення бази даних записів, ефективно обробляти шаблони в якості «будівельних лісів», на якому будується більш потужна програма.

Засіб зіставлення або маршрутизації URL-адреси платформи являє

 собою механізм, за допомогою якого платформа інтерпретує URL-адреси. Деякі фреймворки, такі як Drupal і Django, зіставляють наданий URL-адресу з наперед заданими шаблонами за допомогою регулярних виразів, в той час як інші використовують методи переписування для перетворення наданого URL-адреси в той, який буде розпізнаватися базовим механізмом.

Система зіставлення URL-адрес, яка використовує зіставлення або переписування шаблонів для маршрутизації і обробки запитів, дозволяє використовувати більш короткі «дружні» URL-адреси, збільшуючи простоту сайту і забезпечуючи кращу індексацію пошуковими системами. Наприклад, URL-адресу, що закінчується на «/page.cgi?cat=science&topic=physics», можна змінити на просто «/page/science/фізика». Це полегшує користувачам запам'ятовування, читання і запис URL-адрес і надає пошуковим системам більш точну інформацію про структурне розташування сайту. Підхід з обходом графа також призводить до створення дружніх URL. Більш короткий URL, такий як "/page/science", за замовчуванням існує, оскільки це просто більш коротка форма довшого обходу "/page/science/фізика".

Ajax, скорочення від «Асинхронний JavaScript і XML», є технікою WEB розробки для створення WEB систем. Мета полягає в тому, щоб зробити WEB сторінки більш чуйними, обмінюючись невеликими обсягами даних з сервером за лаштунками, щоб не доводилося перезавантажувати всю WEB сторінку кожен раз, коли користувач відправляє запити на виконання [3]. Це призначено для підвищення інтерактивності, швидкості і зручності використання WEB сторінки.

Через складність Ajax-програмування на JavaScript існує безліч фреймворків Ajax, які мають справу виключно з підтримкою Ajax [3]. Деякі Ajax-фреймворки навіть вбудовані як частина більш великих фреймворків. Наприклад, бібліотека JavaScript jQuery включена в Ruby on Rails.

З ростом інтересу до розробки мультимедійних систем «Web 2.0» складність програмування безпосередньо на Ajax і JavaScript стала настільки очевидною, що з'явилася технологія компіляції, що дозволяє розробникам кодувати на мовах високого рівня, таких як Java, Python і Ruby. Першим з цих компіляторів був Morfik, за яким слідував Google Web Toolkit, через деякий час після нього пішли порти для Python і Ruby в формі Pyjs і RubyJS [16]. Ці компілятори і пов'язані з бібліотеками наборів віджетів та роблять розробку Ajax-додатків для мультимедіа набагато ближчою до розробки настільних додатків.

MVC (Модель-вид-контролер) – це шаблон проектування програмного забезпечення, що часто використовується для розробки призначених для користувача інтерфейсів, який ділить логічну схему пов'язаної програми на три взаємопов'язаних елемента [10]. Це робиться для того, щоб відокремити внутрішнє представлення інформації від способів подання і прийняття інформації від користувача. Дотримуючись архітектурному шаблоном MVC, ці основні компоненти поділяються, що дозволяє повторно використовувати код і виконувати паралельну розробку.

Традиційно використовуваний для графічних користувальницьких інтерфейсів (GUI) робочого столу, цей шаблон став популярним для розробки WEB систем [7].

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

Переваги архітектури MVC:

– одночасна розробка – кілька моделей можуть працювати одночасно над моделлю, контролером і уявленнями;

– висока згуртованість – MVC дозволяє логічно групувати пов'язані дії на контролері разом. Уявлення для конкретної моделі також згруповані

разом;

– слабкий зв'язок – сама структура MVC така, що існує низький зв'язок між моделями, уявленнями або контролерами;

– простота модифікації – майбутня розробка або модифікація легше через поділ обов'язків;

– кілька уявлень для моделі – моделі можуть мати кілька подань.

Взаємодія елементів патерну MVC відбувається так, як це показано на рисунку 1.1.

Рис. 1.1 – Діаграма взаємодії MVC

Ієрархічна модель-уявлення-контролер (HMVC) – це програмний архітектурний патерн, різновид моделі-уявлення-контролера (MVC), аналогічний презентації-абстракції-контроль (PAC), який був опублікований в 2000 році в статті в JavaWorld.

Структурна схема програми, побудованого відповідно до патерну HMVC показано на рисунку 1.2.

Презентація-абстракція-контроль (PAC) – це програмний архітектурний патерн, орієнтована на взаємодію програмна архітектура, яка в деякій мірі схожа на модель-уявлення-контролер (MVC) в тому сенсі, що вона розділяє інтерактивну систему на три типи компонентів, що відповідають за конкретні аспекти функціональності системи [18]. Компонент абстракції витягує і обробляє дані, компонент уявлення форматує візуальне і звукове уявлення даних, а компонент управління обробляє такі речі, як потік управління і зв'язок між двома іншими компонентами.

На відміну від MVC, PAC використовується в якості ієрархічної структури агентів, кожен з яких складається з тріади частин уявлення, абстракції і контролю. Агенти (або тріади) зв'язуються один з одним тільки через контрольну частину кожної тріади. Він також відрізняється від MVC тим, що в кожної тріаді він повністю ізолює уявлення (подання до MVC) і абстракцію (модель в MVC [11]). Це забезпечує можливість роздільної багато поточності моделі та подання, що може дати користувачеві можливість дуже короткого часу запуску програми, оскільки призначений для користувача інтерфейс (подання) може бути показаний до повної ініціалізації абстракції.

Рис. 1.2 – Структурна схема HMVC

Огляд аналогів

Zend Framework

Zend Framework – це об'єктно-орієнтоване середовище WEB систем з відкритим вихідним кодом, реалізована в PHP 7 і ліцензована за новою ліцензією BSD (ліцензія на вільне програмне забезпечення, що накладають мінімальні обмеження на використання та поширення захищеного програмного забезпечення) [5]. Фреймворк являє собою набір професійних пакетів на основі PHP. Фреймворк використовує різні пакети, використовуючи Composer як частину своїх менеджерів залежностей пакетів; деякі з них - PHPUnit для тестування всіх пакетів, Travis CI для служб безперервної інтеграції. Zend Framework надає користувачам підтримку Model View Controller (MVC) в поєднанні з рішенням Front Controller. Реалізація MVC в Zend Framework має п'ять основних областей. Функції маршрутизатора і диспетчера визначають, який контролер запускати на основі даних з URL, і функції контролера в поєднанні з моделлю і представленням для розробки і створення кінцевої WEB сторінки.

Починаючи з Zend Framework версії 2.5, компоненти поділяються на пакети з незалежної версією, а zendframework/zendframework перетворюється в метапакет Composer. Компоненти інфраструктури, введені після поділу, не повинні додаватися в метапакет.

У той час як версія випуску метапакета zendframework/zendframework залишається на 3.0.0, вона буде інструктувати Composer встановлювати останні сумісні версії компонентів каркаса відповідно до оновлення. Таким чином, компонент zend-mvc буде встановлений в його поточній версії 3.1.1, zend-servicemanager в версії 3.3.0 і zend-form в версії 2.10.2.

Офіційно підтримуваний спосіб установки – через менеджер пакетів Composer.

Zend Framework надає метапакет, який включає в себе 61 компонент, але рекомендований спосіб – це встановлення необхідних компонентів інфраструктури окремо. Composer дозволить і встановить всі додаткові залежності.

Каталог config/ має налаштування програми, module/ каталог містить локальні модулі, які фіксуються разом з системою, vendor/ містить код постачальника і інші модулі, керовані незалежно від програми, вміст папки зазвичай управляється Composer.

Модуль Zend Framework має тільки одну вимогу: клас модуля існує в просторі імен модуля і є автоматично завантажуються на початку роботи. Клас модуля надає логіку конфігурації і ініціалізації для системи.

В каталозі config/ містяться конфігурації модуля, в каталозі src/ міститься вихідний код модуля, як визначено в стандарті автозавантаження PSR-4 (специфікація для стандартизації концепцій програмування на PHP, мета полягає в тому, щоб забезпечити сумісність компонентів і надати загальну технічну основу для реалізації перевірених концепцій для оптимальної практики програмування і тестування), в каталозі test/ містяться модульні тести для модуля, а в каталозі view/ містяться сценарії уявлення. Zend Framework підтримує введення з командного рядка для створення структури каталогів.

Контролер є основним записом в системі Zend Framework. Оброблювач фронт-контролера є основним концентратором для прийому запитів і виконання точних дій відповідно до запитів команд. Весь процес запиту та реагування – це маршрутизація і диспетчеризація (що в основному означає виклик правильних методів в класі), який визначає функціональність коду. Це реалізовано інтерфейсом Zend_Controller_Router_. Функціональність маршрутизатора полягає в тому, щоб визначити, які дії необхідно виконати, і, навпаки, диспетчер виконує ці запитані дії. Контролер в Zend Framework пов'язаний в різноманітних структурних каталогах, які забезпечують ефективну маршрутизацію. Основною точкою входу і командним контролером є Zend_Controller_Front, він працює як основа, яка делегує отриману і відправлену роботу. Запит формується і інкапсулюється з екземпляром Zend Controller Request HTTP, як постачальник доступу до HTTP-запитам. Крім того, контролер також надає функції getParam (), які дозволяють збирати запитані змінні.

Дії є важливими функціями. Контролери не працюють без дій. Для цього ми створюємо ще один метод, до імені якого додано дію, і передній контролер автоматично розпізнає його як дію. Дія має метод init(), який показує його особисту природу і недоступний для всіх. Наступні команди виконуються, щоб Zend_Tool міг створити для нас дію. Завдяки використанню стандартного диспетчера всі функції іменуються відповідно до імені дії, після чого додається слово «action». Це призводить до класу дій контролера, який містить такі методи, як indexAction(), viewAction(), editAction() і deleteAction().

Стандартний маршрутизатор є важливим інструментом Front Controller. Тут основні рішення приймаються для того, який модуль, контролер і дію запитуються. Все це обробляється тут. Наступне є структурою за замовчуванням: модуль, контролер, дії.

Головна проблема даного фреймворка це те, що він не так придатний для швидкої розробки систем, як інші фреймворки.

Symfony

Symfony – це фреймворк створення WEB систем PHP і набір повторно використовуваних компонентів / бібліотек PHP [6]. Він був опублікований як безкоштовне програмне забезпечення 18 жовтня 2005 року та випущений під ліцензією MIT.

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

CodeIgniter

CodeIgniter – це WEB середовище швидкої розробки програмного забезпечення з відкритим вихідним кодом, призначене для створення динамічних WEB сайтів з використанням PHP [8].

CodeIgniter заснований на популярному паттерні розробки модель-уявлення-контролер (MVC). Хоча класи контролерів є необхідною частиною розробки під CodeIgniter, моделі та подання є необов'язковими. CodeIgniter також можна модифікувати для використання контролера ієрархічного представлення моделі (HMVC), який дозволяє розробникам підтримувати модульне угруповання «Контролер, Моделі, Вид», розташовану в форматі підкаталогу.

CodeIgniter найчастіше відомий своєю швидкістю в порівнянні з іншими середовищами PHP. У критичній оцінці фреймворків PHP творець PHP Расмус Лердорф виступив на frOSCon в серпні 2008 року, зазначивши, що йому подобається CodeIgniter «тому що він швидше, легше і менше за все схожий на фреймворк».

Вихідний код CodeIgniter підтримується на рівні GitHub і в якості попередньої перегляду версії 3.0rc, має сертифіковане програмне забезпечення з відкритим вихідним кодом з MIT License.

Його плюси:

– орієнтований, в першу чергу, на розробників;

– не потребує будь-яких додаткових залежних об'єктів або іншої підтримки;

– можливість використовувати звичайні сервіси WEB хостингу, використовуючи стандартні бази даних, наприклад MYSQL;

– наявність гарної документації, а також LTS (підтримка протягом тривалого періоду).

Його недоліки:

– відсутній простір імен, з іншого боку, це може збільшити швидкість роботи;

– незручний для модульного тестування, на відміну від інших подібних фреймворків;

– невелика кількість бібліотек, вбудованих безпосередньо у фреймворк;

– є досить застарілим фреймворком, що не підтримують сучасні PHP-функції;

– наявність проблем з безпекою, які були досить явними і протягом багатьох років так і не були усунені командою розробників.

FuelPHP

FuelPHP – це платформа WEB систем з відкритим вихідним кодом, написана на PHP, яка реалізує шаблон НMVC [7].

Проект FuelPHP стартував в жовтні 2010 року. Основний внесок до FuelPHP є компанія Verton, Джелмер Шрудер, Ден Хорріган Філіп Осетра і Франк де Йонг. У листопаді 2013 Стів Вест приєднався до команди розробників.

Перша версія FuelPHP (FuelPHP 1.0) була розроблена в репозиторії GitHub під назвою Fuel. Ще один репозиторій GitHub під назвою FuelPHP був створений для розробки другої версії (FuelPHP 2.0).

Ідеї проекту:

– побудова фреймворка на основі кращих ідей з інших фреймворків;

– фреймворк повинен забезпечувати потужні функціональні можливості, з ним має бути легко працювати і він повинен мати легку кодову базу;

– з урахуванням орієнтації спільноти розробників (підтримка).

Огляд архітектури:

– каскадна файлова система (заснована на платформі Kohana): структура каталогів, частково заснована на просторах імен, використовуваних класами;

– гнучкість: майже кожен компонент базової структури може бути розширений або замінений;

– модульність: додатки можуть бути розділені на модулі;

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

Його плюси:

– кешування необов'язково;

– аутентифікація пакетів;

– можливість постійної розробки;

– маршрутизація URL.

Його недоліки:

– досить складний фреймворк для вивчення новачками (невелика кількість документацій);

– досить новий фреймворк, який, поки що, мало де підтримується;

– невеликі вкладення спільноти розробників програмного забезпечення з відкритим вихідним кодом (наприклад, в порівнянні з Phalcon).

Висновки

Отже, структура MVC є одна з найбільш вживаною в розробці фреймворку, тому що вона надає розробникам незалежність від структурних компонентів в розробці системи та є найбільш легшою до сприйняття. Також, систему побудовану за даною архітектурою можна убезпечити від файлового падіння, тобто якщо буде відсутня «модель», то «контролер» зможе попередити збій системи простою перевіркою на існування файлу на хостингу.

Новий розроблений фреймворк повинен бути придатний для швидкої розробки систем в порівнянні з Zend Framework. В порівнянні з Symfony та FuelPHP, повинен бути легко зрозумілим. В порівнянні з CodeIgniter повинен підтримувати сучасні PHP функції.

 

РОЗДІЛ 2