Skip to content

2. Підхід до розробки MVC у веб/PHP

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

  1. Почнемо з визначення всіх представів додатка. Це веб-сторінки, які відображаються користувачеві. При розробці представів ми будемо виходити з точки зору користувача. Вирізняють три типи представів:
    • форма введення даних, призначена для отримання інформації від користувача. Зазвичай вона має кнопку для надсилання введених даних на сервер.
    • сторінка відповіді, яка служить виключно для надання інформації користувачеві. Вона часто містить одне або кілька посилань, що дозволяють користувачеві перейти до іншої сторінки додатка.
    • змішана сторінка: контролер надіслав клієнту сторінку, що містить інформацію, яку він сам згенерував. Ця сама сторінка знадобиться клієнту для передачі контролеру нової інформації, отриманої від користувача.
  1. Кожен вигляд дасть початок сторінці PHP. Для кожної з них:
    • буде визначено зовнішній вигляд сторінки
    • буде визначено, які її частини є динамічними:
      • інформація, призначена для користувача, яку контролер повинен передати у вигляді параметрів до подання PHP. Просте рішення полягає в наступному:
        • контролер поміщає у словник $dReponse інформацію, яку він хоче надати вигляду V
        • контролер відображає представлення V. Якщо воно відповідає вихідному файлу V.php, це відображення досягається просто за допомогою інструкції include V.php.
        • попереднє включення є включенням коду в контролер. Словник $dReponse, заповнений ним, доступний безпосередньо через код V.php.
      • Дані введення, які повинні бути передані до головної програми для обробки. Вони повинні бути частиною форми HTML (тег <form>).
  1. Можна схематично зобразити вхідні та вихідні дані кожного виду
  • вхідні дані — це дані, які контролер повинен надати сторінці PHP
  • виходи — це дані, які сторінка PHP повинна надати контролеру додатка. Вони є частиною форми HTML, і контролер отримає їх за допомогою операції типу $_GET["param"] (метод GET) або $_POST["param"] (метод POST).
  1. Часто кінцева сторінка, що надсилається клієнту, є не окремим видом, а комбінацією видів. Наприклад, сторінка, що надсилається користувачеві, може мати такий вигляд:

Зона 1 може бути заголовним банером, зона 2 — меню, а зона 3 — зоною вмісту. У PHP цю комбінацію можна отримати за допомогою такого коду HTML/PHP:

<table>
    <tr>
        <td><?php include zone1.php ?></td>
    </tr>
    <tr>
        <td><?php include zone2.php ?></td>
        <td><?php include zone3.php ?></td>
    </tr>
</table>

Цей код можна зробити динамічним, написавши:

<table>
    <tr>
        <td><?php include $dReponse['urlZone1'] ?></td>
    </tr>
    <tr>
        <td><?php include $dReponse['urlZone2'] ?></td>
        <td><?php include $dReponse['urlZone3'] ?></td>
    </tr>
</table>

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

  • визначити шаблон, який слід використовувати
  • визначити елементи, які слід включити до неї
  • запросити відображення шаблону
  1. Ми напишемо код PHP/HTML для кожного шаблону відповіді. Зазвичай цей код є простим. Код із наведеного вище прикладу міг би виглядати так: 
<?php
    // ініціалізації для тестування без контролера
...
?>
<html>
    <head>
      <title><?php echo $dReponse['titre'] ?></title>
      <link type="text/css" href="<?php echo $dReponse['style']['url'] ?>" rel="stylesheet" />    
    </head>
  <body>      
    <table>
        <tr>
            <td><?php include $dReponse['urlZone1'] ?></td>
        </tr>
        <tr>
            <td><?php include $dReponse['urlZone2'] ?></td>
            <td><?php include $dReponse['urlZone3'] ?></td>
        </tr>
    </table>
  <body>
</html>

Слід використовувати таблицю стилів, коли це можливо, щоб мати змогу змінювати «зовнішній вигляд» відповіді без необхідності вносити зміни до коду PHP/HTML.

  1. Для кожного елементарного виду буде написано код PHP/HTML. Найчастіше він матиме такий вигляд: 
<?php
     // можливі деякі ініціалізації, зокрема на етапі налагодження
    ...
?>

<balise>
...
         // тут ми намагатимемося мінімізувати PHP-код
</balise>

Слід зазначити, що елементарний вигляд вбудовується в модель. Його код HTML вбудовується всередину коду моделі. Найчастіше останній вже містить теги <html>, <head>, <body>. Тому ці теги рідко зустрічаються в елементарному вигляді.

  1. Можна проводити тестування різних шаблонів відповідей та елементарних подань
  • тестується кожна модель відповіді. Якщо модель називається modele1.php, то за допомогою браузера буде зроблено запит на URL http://localhost/chemin/modele1.php Модель очікує значення від контролера. Тут ми викликаємо її безпосередньо, а не через контролер. Модель не отримає очікуваних параметрів. Щоб тестування все ж було можливим, ми самостійно ініціалізуємо очікувані параметри за допомогою констант на сторінці PHP цієї моделі.
  • Кожна модель тестується, як і всі елементарні види. Це також час для розробки перших елементів використовуваних таблиць стилів.
  1. Далі ми пишемо логіку додатка:
  • Контролер, або головна програма, зазвичай керує кількома діями. У запитах, що надходять до нього, має бути визначена дія, яку потрібно виконати. Це можна зробити за допомогою параметра запиту, який ми тут назвемо «action»:
    • якщо запит надходить із форми (<form>), цей параметр може бути прихованим параметром форми: 
<form ... action="/C/main.php" method="post"  ...>
<input type="hidden" name="action" value="uneAction">
...
</form>
  • (продовження)
    • якщо запит надходить з посилання, його можна налаштувати: 
 <a href="/C/main.php?action=uneAction">lien</a>

Контролер може спочатку зчитати значення цього параметра, а потім делегувати обробку запиту модулю, відповідальному за обробку цього типу запитів. Тут ми розглядаємо випадок, коли все контролюється єдиним скриптом під назвою main.php. Якщо додаток має обробляти дії action1, action2, ..., actionx, можна створити в контролері окрему функцію для кожної дії. Якщо дій багато, контролер може перетворитися на «динозавра». Також можна створити скрипти action1.php, action2.php, ...,actionx.php, які відповідають за обробку кожної з дій. Контролер, що має обробляти дію actionx, просто завантажить код відповідного скрипта за допомогою інструкції на кшталт include "actionx.php". Перевага цього методу полягає в тому, що робота відбувається поза кодом контролера. Таким чином, кожен член команди розробників може працювати над скриптом обробки дії actionx відносно незалежно. Включення коду скрипта actionx.php у код контролера під час виконання також має перевагу у вигляді зменшення обсягу коду, що завантажується в пам’ять. Завантажується лише код обробки поточної дії. Таке включення коду призводить до того, що змінні контролера можуть конфліктувати зі змінними скрипта дії. Ми побачимо, що можна обмежити змінні контролера кількома чітко визначеними змінними, яких слід уникати у скриптах.

  • Ми будемо систематично прагнути ізолювати бізнес-код або код доступу до постійних даних в окремі модулі. Контролер — це свого роду керівник команди, який отримує запити від своїх клієнтів (веб-клієнтів) і доручає їх виконання найбільш підходящим виконавцям (бізнес-модулям). Під час написання контролера ми визначатимемо інтерфейс бізнес-модулів, які потрібно написати. Це стосується випадків, коли ці бізнес-модулі ще не створено. Якщо вони вже існують, то контролер адаптується до інтерфейсу цих існуючих модулів.
  1. Ми напишемо каркас бізнес-модулів, необхідних контролеру. Наприклад, якщо контролер використовує модуль getCodes, який повертає масив рядків, то на першому етапі можна обмежитися таким кодом: 
function getCodes(){
    return array("code1","code2","code3");
}
  1. Після цього можна перейти до тестування контролера та відповідних скриптів PHP:
  • контролер, скрипти дій, моделі, представлення та ресурси, необхідні для роботи додатка (зображення тощо), розміщуються у папці DC, пов’язаній із контекстом C додатка.
  • Після цього додаток тестується, а перші помилки виправляються. Якщо main.php є контролером, а C — контекстом додатка, буде викликано URL http://localhost/C/main.php. Наприкінці цього етапу архітектура додатка стає працездатною. Цей етап тестування може бути складним, оскільки інструментів для налагодження мало, якщо не використовувати сучасні середовища розробки, які, як правило, є платними. Можна скористатися командами echo "message", які записують дані у потік HTML, що надсилається клієнту, і, отже, відображаються на веб-сторінці, яку показує браузер.
  1. Нарешті, ми пишемо бізнес-класи, необхідні контролеру. Зазвичай це класична розробка класу PHP, який найчастіше є незалежним від будь-якого веб-додатку. Спочатку його тестують поза цим середовищем, наприклад, за допомогою консольного додатка. Після написання бізнес-класу його інтегрують в архітектуру розгортання веб-додатку та перевіряють правильність інтеграції. Так процедуру повторюють для кожного бізнес-класу.
https://stahe.github.io
Цей навчальний курс, написаний Сержем Тахе, надається громадськості на умовах Creative Commons «Вказання авторства — Без комерційного використання — Поділитися на рівних умовах 3.0 без змін.