Програмування на PHP - Розробка відповідно до підходу MVC Модель - Вид - Контролер - Зворотній зв’язок -

Привіт розробники,

програмування

сьогодні я напишу вам допис про демістифікацію концепції програмування на PHP із підходом Model-View-Controller (MVC для друзів).

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

  • Модель, яка об'єднує все, що стосується бізнесу (професійні аспекти програми)
  • Погляд, що включає все, що пов’язано з візуалізацією
  • Контролер, який об'єднує все, що пов'язано з входами/управлінням потоком/виходами програми

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

МОДЕЛЬ

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

Цей пункт слід приймати в широкому розумінні концепції, наприклад, елементи у цьому списку потрапляють у поле зору:

  • згенерувати html
  • згенерувати xml
  • згенерувати PDF
  • тощо.

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

КОНТРОЛЕР

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

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

Дія буде відповідати, наприклад:

  • вимагати відображення веб-сторінки
  • викликати форму введення
  • подати заповнену форму
  • подати запит на створення PDF-документа
  • відновити дані у форматі xml - -
  • сортувати дані таблиці за клацанням заголовка стовпця
  • змінити сторінку при натисканні елемента пагінації
  • тощо.

Відповідно до вищезазначеного принципу,
ДЛЯ КОЖНОЇ ДІЇ, ДОСТУПНОЇ НА ВЕБ-САЙТІ, ПОВИНЕН ВІДПОВІДАТИ ОДИНОЧНОГО І ОДИНОЧНОГО КОНТРОЛЕРА, ЯКИЙ БУДЕ ЄДИНИМ ВХОДОМ ЗАЯВКИ НА ЦЮ ОБРОБКУ

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

ЗАПИТ СЕРВЕРА

Як вам відомо, у браузера є лише один унікальний спосіб спілкування з веб-сервером: URL.
Щоб веб-сервер міг диференціювати дії та не заплутувати кисті, обов’язковим буде наявність унікальної відповідності між URL та дією.
Отже,
КОЖНА ДІЯ, ДОСТУПНА НА ВЕБ-САЙТІ, ПОВИННА ПОВІДОМЛЯВАТИ ОДИНУ І ОДИНУ URL-адресу, ЩО БУДЕ ЄДИНИМ ВХОДОМ САЙТА ДЛЯ ЦЕЙ ОБРОБКИ

ОРГАНІЗАЦІЯ КОДЕКСУ ДЖЕРЕЛ

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

Тепер давайте перейдемо до більш технічного аспекту: середовище виконання PHP має особливість, яка є як сильним, так і слабким боком: PHP говорить "без громадянства", що просто означає, що він не зберігає нічого в пам'яті між кожним запитом.
Це точно так, ніби він вимикається і знову вмикається між кожним дзвінком. Як перезавантаження комп’ютера між кожним натисканням клавіші, це дратує, так? Ну, не до тих пір, поки це !

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

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

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

Для спрощення у конфігурації веб-сервера чітко визначено кореневий каталог (як правило,/www /), який буде використовуватися для зберігання всіх файлів, що стосуються вашої програми (.php, .jpeg, .css, .js, та ін.) Також можна створити стільки підкаталогів, скільки потрібно для полегшення організації вашого коду.

БЕЗКОШТОВНІ ТОЧКИ ВХОДУ НА САЙТ

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

Ваша програма розпочнеться безпосередньо у файлі, що знаходиться в /abc/def/fichier.php. Чому ні, скажете ви мені? Добре, давайте просунемо логіку далі.

Ваша програма розпочнеться безпосередньо у файлі, що знаходиться в /abc/def/ghi/jkl/mno/login.php

Тепер повернімось до наших голов: вашій програмі потрібно конкретне середовище виконання, щоб весь вихідний код міг працювати безперебійно.
Отже, щоб відновити це середовище, і оскільки ви розумний розробник, ви, ймовірно, створите каталог у вашій деревній структурі під/www/bootstrap /, щоб розмістити всі сценарії ініціалізації: PDO, константи, автозавантажувач, максимальний час роботи тощо.
Суть у тому, що з кожним новим сценарієм вам доведеться жонглювати require_once __DIR_. '/././././bootstrap/PDO.php; число /./ дорівнює 3 або 4 ?
Це буде те саме, що стосується включення файлів шаблонів для створення відповіді.
Це буде дуже швидко некерованим і проклятим здуттям живота, повірте мені, і ви в кінцевому підсумку будете проклинати себе та своїх нащадків протягом поколінь і поколінь

ОДИН ТОЧКИ ВХОДУ НА САЙТ

Інший підхід, який називається централізованим, значно полегшить ваше життя і отримає вигоду від системи, яка працює дуже швидко і не потребує надто багато зусиль.
Будемо вважати, що всі запити, що надходять на сервер, є перенаправлено на одній точці входу, PHP-файл, викликаний, увага! Барабанні рулони: index.php. Ну, ти скажеш мені, яке божевілля, а? Врешті-решт час від часу.
Отож, оскільки цей файл отримає абсолютно всі запити, нам буде дуже легко перейти до завантаження нашого середовища виконання.
Немає більше болючої гімнастики, просто на початку файлу простий включає 'bootstrap/PDO.php'; подальші дії з файлами, необхідними для запуску.
І що не є незначним, так це те, що ви знаходитесь у корені вашого сайту, дуже легко створити константу, яка містить фізичний шлях від кореня сайту до сервера, класичне визначення ('DIR_ROOT', __DIR__. DIRECTORY_SEPARATOR); .

Щоб досягти цього результату: 2 можливі способи: або ви налаштуєте веб-сервер так, щоб він виконував переспрямування (моє улюблене рішення), або ви кодуєте всі свої URL-адреси, щоб змусити переспрямувати приблизно так: http://www.monsite.fr /index.php?page=login або http://www.monsite.fr/index.php?page=loginsubmit .

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


Трохи осторонь все в порядку, оскільки словниковий запас дуже важливий, коли мова заходить про техніку, слід зазначити:

Коли ви знаходитесь у браузері (Firefox, Chrome, Opera, Safari.), Ви поговорите проURL-адреса, але коли ви перейдете на сторону веб-сервера, ви будете говорити про це ДОРОГА. Різниця тонка, але важлива: маршрут - це URL-адреса, яка була проаналізована. Тобто URL-адреса була повністю проаналізована для вилучення всіх компонентів окремо згідно з RFC3986.

Після того, як будівельні блоки URL-адреси відомі, веб-програмі доведеться порівняти їх із внутрішніми налаштуваннями, щоб спробувати знайти, чи має він достатні ресурси, щоб мати змогу створити відповідну відповідь та надіслати її в браузер клієнта. . Цей важливий крок називається МАРШРУТОМ. і базується на одному або декількох таблиця маршрутизації . Якщо жоден маршрут не відповідає URL-адресі, програма надішле відповідь про помилку 404.

У наших прикладах таблиця маршрутизації вказує, що:
- коли page = "login", вам доведеться перенести потік обробки в \ User \ Controller \ Login.php,
- коли page = "loginsubmit", вам доведеться перенести потік обробки в \ User \ Controller \ LoginSubmit.php,

Тепер ми можемо завершити твердження з самого початку:

КОЖНА ДІЯ, ДОСТУПНА НА ВЕБ-САЙТІ, ПОВИННА ПОВІДОМЛЯВАТИ ОДИН І ОДИНИЙ URL-адресу/МАРШРУТ/КОНТРОЛЕР, ЯКИМИ БУДУТЬ ЄДИНИМИ ВХОДАМИ САЙТУ ДЛЯ ЦЕЙ ОБРОБКИ

Підсумовуючи схематично:

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

Ми підходимо до кінця брифінгу з концепції MVC.

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

Хороший код для всіх

Помилка в цій новині? Повідомте нас !