Компонентний (блоковий) підхід

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

В компонентом підході залишаються все ті ж 3 елемента: Model, View і Controller. Але дуже важлива відмінність: в чистому MVC користувач звертався до Controller, однак, набагато логічніше звертатися до View. І як раз в компонентом підході йде звернення саме до зазначеного елементу.

Відео: Компонентний підхід у побудові WEB-додатків

Другий найважливіша відмінність полягає в тому, що Controller розбивається на кілька частин, компонентів, кожен з яких відповідає за свою частину. Наприклад, блок з новинами, панель користувача, блок з коментарями і так далі. Зрозуміло, вся обробка йде у відповідному блоці. Наприклад, якщо потрібно обробити додавання нового коментаря, то ця обробка поміщається в компонент, який відповідає за коментарі. А не все в одну купу, як це було в MVC (Коли вся обробка відправлялася в 1 файл, controller.php).

Давайте з Вами розберемо компонентний підхід на прикладі з минулої статті. Почнемо з файлу index.php, що належить шаблоном.

 Коментарі 
require_once "comments.php" - // Підключення компонента, що відповідає за коментарі 
lt ;?php 
for($ i =0- $ i lt; count($ comments) - $ i++){ 
echo "".$ comments[$ i] ["Name"].":".$ comments[$ i] ["Text"].""- 
?gt;

Тепер розглянемо файл comments.php, відповідальний за коментарі:

Відео: Superblocks: How Barcelona is taking city streets back from cars

lt ;?php 
 require_once "Model.php"-// Підключаємо Модель 
/ * Тут може бути обробка різних форм, що відносяться до коментарів * / 
 $ comments = getComments() -// Якась функція в Моделі, повертаючись двовимірний масив з коментарями 
?gt;

Може здатися, що нічого не змінилося. Адже залишився той же PHP-код в файлах шаблону. Однак, нам вдалося зробити так, щоб дизайнер і тільки дизайнер вирішував, які блоки і де виводити. Це дуже значимий результат. Тепер дизайнер може в своєму шаблоні, взяти весь цей код підключення коментарів і переставити в інше місце або, наприклад, взагалі видалити. У той же час, якщо програміст придумає якийсь швидший спосіб отримання коментарів, він спокійно виправить Model, ніяк не зраджуючи View.

Даний спосіб ідеальний для невеликих сайтів, наприклад, сайтів-візиток. Однак, мінуси у даного способу є:

Як і раніше, залишився PHP-код в шаблон.
Для великих сайтів даний спосіб не підійде. Адже у сайту є безліч повторюваних елементів, наприклад, шапка сайту (не просто одна картинка, а деяка структура HTML-коду). І якщо буде потрібно змінити її, то буде потрібно міняти всі сторінки вручну. А якщо їх буде 1000?

У зв`язку з цими мінусами, були придумані шаблонизатор, які позбавлені цих двох мінусів. Їх існує велика кількість, наприклад, Smarty, але я Вам рекомендую створити свій. У будь-якому випадку, у кожного шаблонізатора будуть свої мінуси. Наприклад, наявність службових конструкцій в шаблоні (Саме службових конструкцій, а не PHP-коду), Які є тим же кодом, просто у вигляді HTML-коментарів, який в шаблонизатор перетвориться в PHP-код. Або якщо винести всю обробку в шаблонизатор, залишивши ідеально чистий Шаблон з тільки HTML-кодом без всяких службових конструкцій, то тоді доведеться змиритися з деякою залежністю програмної частини і зовнішнього вигляду. Це означає, якщо принципово змінити висновок чого-небудь (наприклад, був список, що випадає, а тепер потрібно вивести все в тезі lt;pgt;), то доведеться змінювати програмну частину.

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

Поділися в соціальних мережах:

Схожі