Програмиране в PHP - Разработка според модела на MVC подход - Изглед - Контролер - Обратна връзка -

Здравейте разработчици,

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

Като се има предвид, че в днешно време уеб приложенията имат жалка тенденция да имат наднормено тегло или дори затлъстяване, важно е да се организира изходният код по такъв начин, че да може да улесни, от една страна, разработването на нови функционалности, а от друга страна, поддържане на съществуващ код. От тази гледна точка опитът показва, че е напълно възможно да се отдели изходният код на три отделни части, свързани с всеки аспект на обработката:

Моделът, който обединява всичко, свързано с бизнеса (професионални аспекти на приложението)
Изгледът, който включва всичко, свързано с изобразяването
Контролерът, който обединява всичко, свързано с входовете/управлението на потока/изходите на приложението

Изхождам от строг подход, за да представя добре общата концепция. С опит може да успеете малко да отпуснете този подход, но засега никакво отклонение няма да ви е от полза, освен да се объркате.

МОДЕЛЪТ

Както е посочено по-горе, този аспект включва всичко, което е специфично за бизнес слоя на приложението.
Под бизнес слой трябва да се разбира, че това съответства на добавената стойност на приложението.
Когато работите например върху приложение за управление, бизнес слоят ще включва управление на акаунти (създаване, модифициране, изтриване.), Категории, изчисления на салда съгласно действащите правила, управление на закръгляване, издания и др.
От едно приложение в друго бързо ще осъзнаете, че някои бизнес аспекти са често срещани и многократно използвани: свързване с акаунт, прекъсване на връзката, достъп до база данни (PDO).
Така че, най-вероятно ще се чудите за най-добрия начин за повторно използване на кода между приложенията много лесно и неизбежно ще срещнете обектно ориентирано програмиране (OOP), проектирано с тази идея за преносимост от самото начало. Ще подкрепям този подход в този пост.

Този елемент трябва да бъде взет в широкия смисъл на понятието, например елементите в този списък попадат в изгледа:

генериране на html
генерирайте xml
генериране на pdf
и т.н.

Трябва да се разбере, че зрението е a прекратяване на лечението. Гледката е край, тя трябва да се занимава само с генериране на добре автономно (доколкото е възможно) елемент, който трябва да бъде изпратен на браузъра.
По-ясно: мерникът е пасивен, в параметъра е необходимо да се предадат всички елементи, необходими за работата му при генериране. Това предполага, че преди извикването на изгледа, текущият процес първо трябва да събере колективно стойности, променливи и други данни, които ще се използват при генериране на визуализатора.
Изгледът трябва да има само много ограничен достъп до други части на приложението. В резултат на това единствените функции, до които има достъп, трябва да се отнасят само за преглед, например функция за избягване на опасни символи, функция за форматиране на текст.
Във всеки случай не трябва да се обръща към бизнес слоя или контролера.

КОНТРОЛЕРЪТ

Той е диригент на триото, той е входната точка на всяко лечение, той контролира програмния поток (процесния поток), извиква елементите на бизнес слоя, събира данните за отговора, извиква елементи за преглед и изпраща отговор на браузър в самия край на обработката.

Тук има много важен момент, който трябва да се схване, е понятието входна точка на всяко лечение.
Трябва да се разбере, че взаимодействието с уеб приложение е еквивалентно на извършването на поредица от действия.

Действие ще съответства например на:

поискайте показване на уеб страница
извикайте формуляр за въвеждане
изпратете попълнен формуляр
поискайте генерирането на pdf документ
възстановяване на данни в xml формат
сортирайте данните в таблица, като щракнете върху заглавката на колона
промяна на страницата при щракване на елемент за пагинация
и т.н.

В съответствие с горния принцип,
ЗА ВСЯКО ДЕЙСТВИЕ, ДОСТЪПНО НА УЕБСАЙТА, ТРЯБВА ДА СЪОТВЕТЯ ЕДИНСТВЕН И ЕДИНЕН КОНТРОЛЕР, КОЙТО ЩЕ БЪДЕ ЕДИННАТА ВХОДНА ТОЧКА НА ЗАЯВКАТА ЗА ТАЗИ ОБРАБОТКА

Не се притеснявайте, на уебсайтове с определен размер не е необичайно да намерите над 1000 контролера. които съответстват на 1000 възможни действия в сайта.

ЗАЯВКА ЗА СЪРВЪР

Както знаете, браузърът има само едно и уникално средство за комуникация с уеб сървър: URL.
За да може уеб сървърът да разграничава действията и да не се заплита четките, ще е задължително да има уникална кореспонденция между URL и действие.
Следователно,
ВСЯКО ДЕЙСТВИЕ, ДОСТЪПНО НА УЕБСАЙТА, ТРЯБВА ДА СЪОТВЕТЕ ЕДИН И ЕДИНЕН URL, КОЙТО ЩЕ Е ЕДИНСТВЕНАТА ТОЧКА ЗА ВХОД НА САЙТА ЗА ТАЗИ ОБРАБОТКА

ОРГАНИЗАЦИЯ НА ИЗТОЧНИКОВИЯ КОД

От самото начало говоря за понятието входна точка, от съществено значение е да го разберем добре, защото това ще повлияе пряко на начина за организиране на изходния код на приложение.