
PHP для маленьких. MVC по-своєму
Хочу запропонувати легкий курс статей, який би допоміг початківцям, а у людей похилого віку викликав би тільки теплу посмішку на обличчі за прожиті роки, спрямований на просте освоєння концепції MVC.
Концепція
Курс статей, покликаний розповісти новачкові про те, як же насправді влаштовані такі страшні гіганти, як PHP MVC Фреймворки.
Курс ні в якому разі не претендує на звання "Всеосяжний посібник: "Зроби сам все те, що вже давно винайдено" ", але допоможе зрозуміти найменшим і тільки початківцям програмістам світу веб, яким чином все це написано, та ще й працює. Але перш ніж завантажувати вас тоннами коду, необхідно розібратися з самим поняттям MVC. Що це таке?
І ось, PHP профі вже не можуть терпіти, не вставивши: "Знову ця банальщина про ази, патерни та інше"... " Заспокойтеся, дорогі мої, не забувайте, що колись і ви не розуміли половину того, що зараз у вас викликає нестримний сміх, колись і вам доводилося сидіти з повними горем очима після чергового «@ include ();» «і саме ви колись також не знали про повсякденне» Модель-Уявлення-Контролер «». Тому давайте не будемо глумитися над маленькими і тільки початківцями Р шниками і дозволимо їм відчути себе такими ж художниками, або навіть творцями свого коду, якими вже є ви! А також не забувайте, дорогі гуру, що повторення - це мати вчення.
Тепер про нагальне. MVC - це лише набір шаблонів проектування (патрових) вашої програми, який передбачає поділ вашого коду на три складові: Model (Модель), View (Представлення), Controller (Контролер). Простіше кажучи, MVC - це набір набоїв, що дозволяє розділяти може бути трохи сумбурний код, на три незалежні частини - дані-вид-логіка. Ось і все! Бути може ви вже давним-давно використовували таку архітектуру додатків, але не знали такої красивої назви. Але ось тепер ви можете трохи розпрямити плечі, надути груди колесом і задерти голову вгору зі словами: "А я ще нічого!" ".
Але цього поки мало, слід трохи розібратися з кожним з цих трьох китів, тому давайте швиденько розчистимо поле для уявлень і розгорнемо барвисту і яскраву картину світобудови MVC.
Отже, все що ми бачимо на сторінці, що можна помацати, посувати - це і є уявлення. Вона може включати HTML розмітку, скрипти, стилі та інші елементи інтерфейсу користувача. Але вистава - це всього лише сцена нашого театру, яка не має нічого більш, ніж красиве оформлення. Так, сцена може бути красиво-оформленою, з хорошою постановкою світла, декорації можуть бути виконані з приголомшливих матеріалів, але без акторів вона нікому не потрібна, вона - шуршачна обгортка.
Дійовими особами нашого театру виступають актори, які задовго до прем'єри готуються до своєї ролі; годинами репетирують монологи, ставлять мову, грають бровами. Актори, як ніхто інший знають про свого персонажа все. Ці актори і є моделі концепції MVC. У кожної моделі є набір даних, якими можна оперувати, використовуючи певні методи.
Ось у нас є сцена, є актори..., здавалося б, що ще потрібно для захоплюючої вистави? Думаю, не вистачає оригінального сценарію. Сценаристи повинні поставити все по своїх місцях: вказати акторам де їм грати, розставити гармонійно декорації, підтримувати логічний ланцюжок подій протягом усієї вистави. Ви, напевно, вже зрозуміли, що мова йде про контролерів, на плечах яких лежить підтримка зв'язку користувача з додатком.
Ось тепер наш спектакль готовий приймати оплески глядачів, які перебувають у захваті від постановки.
Але на практиці, досягти такого ефемерного успіху виходить не відразу, тому що концепція MVC виходить далеко за межі цих трьох букв, також далеко як реалізація і застосування цього набору шаблонів проектування. Спочатку складно зв'язати трьох китів, а тим більше лаконічно описати контролер, який не був би схожий на окремий модуль, що містить безкрайнє число бізнес-логіки, купи перевірок і валідаторів. Додайте до всього цього шепоту «вмілих ручок» «при роботі з моделями, і вуаля - свіжоспечений шматочок» товстого контролера «» подали до столу. У цьому немає нічого страшного, і навіть образливого, дорогі програмісти, адже якщо ви це побачили - значить ви ростете!
Та й до речі, що ж таке товстий контролер? Термін "Товстий Тупий Потворний Контролер" "з'явився на знак протесту проти затятого бажання програмістів звалити всі операції з даними на контролери. Так, так, звалити неповторну гру акторів на плечі сценаристів.
Вперше опублікована концепція MVC свідчила, що контролери повинні виступати в ролі "прошарку між моделями, представленнями, і вхідними запитами" ". Однак, в наслідок, в 90-х роках терміни трьох китів були переосмислені, після виходу книги Івара Якобсона "Object-Oriented Software Engineering: A Use Case Driven Approach «», в якій була описана система, схожа з MVC, але реалізує абсолютно інші цілі. Так, наприклад, контролер Якобсона повинен виступати в ролі контейнера для інших об'єктів підсистеми. Відчуваєте різницю? Тому, дорогі малюки, піднесіться духом, якщо спочатку у вас будуть виходити саме товсті контролери. Ви можете легко парирувати ситуацію, склавши руки на грудях зі словами: "Я просто дотримуюся іншої концепції" ".
Тонкість і витонченість хороших же контролерів полягає саме в можливості виступати посередником між двома іншими китами.
Тепер повернемося до наших "акторів" ". Уявіть виставу, в якій всі актори тільки займаються тим, що читають завчені ролі, не вкрала емоціями всю яскравість щастя або глибину трагедії подій, що відбуваються. А тепер давайте уявимо моделі, які тільки цим і займаються, що виступають в ролі сумних акторів, не роблячи ніяких дій з даними, крім як реалізуючи примітивний доступ до бази даних. Як ви думаєте, якщо хтось покладе свої обов'язки на іншого, чи добре це буде?
Правильна відповідь: ТТУК.
Необхідно просто підгодувати моделі до потрібного стан, вирізаючи зайвий з контролерів, для того щоб кожен займався своєю справою.
Що ж стосується декорацій нашої сцени, дороги програмісти, то давайте-но на секунду згадаємо репліку з доброго радянського мультфільму: "Ви що ж, за мене і їсти будете?" "... Не варто перекладати на уявлення розносольні роботи, ніяк не пов'язані з його натурою.
Звичайно ж, дробити концепцію MVC можна з точністю до кожного застосовуваного шаблону у фреймовику, головною ж метою цієї статті було легке і ненав'язливе донесення короткої, але барвистої інформації про таку повсякденну концепцію як Модель-Подання-Контролер.