Съдържание
Попитайте ме коя рамка да използвам и вероятно ще имам настървен момент на старица и ще ви кажа, че всички рамки са толкова лоши, колкото една друга. Което не означава, че всички те са лоши, точно, но в PHP имаме невъобразимо голям брой рамки (обикновено цитирани като N + 1, където N е броят на PHP разработчиците в света) и всички те вероятно имат смисъл на човека, който ги е измислил.
Изборът на рамки вероятно е по-добър от опита да се използва само една рамка, независимо какво точно се опитвате да изградите, защото тя е „най-добрата“ (по каквато и да е мярка за „най-добра“). Този избор на рамкови предложения означава, че можете да изберете нещо, което отговаря на нуждите на проекта и дори може да бъде документирано. Рамките на всяка платформа наистина са там, за да предоставят структура, многократно използваеми модули и библиотеки и обикновено избягват всички скучни и повтарящи се задачи, свързани с изграждането на една и съща функционалност отново и отново. Например при изграждането на CMS, нещо трябва да обработва и валидира полета на формуляра за мен; ако се оставя на собствените си устройства, може да пропусна нещо важно и много бих предпочел да направя елементите на всеки проект, които са различен, а не тези, които са едни и същи всеки път!
Рамки с пълен стек
Пълно стековите рамки, като Zend Framework, могат да бъдат приятно начало за разработчик, без много архитектурен опит. Това дава добра структура, на която да закачите ново приложение, а около него има добра „екосистема“ - много книги, уроци и някаква разумна документация. Ако се опитвате да създадете голямо приложение, което ще се поддържа от много хора, тогава една популярна, изчерпателна рамка вероятно ще бъде добър избор, тъй като ще диктува доста структура и ще бъде добре позната и разбрана.
Наличието на структура, която да помогне за разделянето, винаги е добро; в началото на кариерата си работех с някои много младши разработчици и се опитаха да ги научат на модела MVC (Model View Controller), който беше относително нов по това време. Взехме решението да използваме Smarty в слоя изглед; отчасти, за да могат дизайнерите да работят по-лесно с шаблоните, и отчасти така, че когато някой дойде на бюрото ми и каза „как да направя X със Smarty?“ Бих могъл да кажа „не правете X в изгледа!“ (девет пъти от 10, това беше отговорът). Наличието на рамки ни помага да намерим същото разделение и в други части на нашето приложение. Много от тях поддържат интеграция срещу шаблонния слой като Smarty или новия ми фаворит Twig, така че можете да вземете тези инструменти със себе си, която и рамка да изберете.
Облекчете товара
Има много по-леки рамки от Zend Framework, например работя доста с CodeIgniter. Толкова ли е изчерпателна и стабилна като Zend Framework? Не, не е така. Но като помощна рамка за бързо изграждане на приложение е полезно. Като цяло, рамки с по-малко функционалност „помощник“ могат да бъдат по-лесни за ориентиране, тъй като е много по-очевидно как парчетата вървят заедно. В непозната рамка (за мен това е почти всичко), автоматичните битове затрудняват работата и отстраняването на грешки.
Това усещане за „загуба в нова рамка“ е неизбежно и напълно разочароващо; дори опитен разработчик се чувства като начинаещ, когато не знае как нещо работи. Ако наистина нямате късмет, ще изберете рамка, чийто IRC канал ще ви каже, че и вие сте идиот! Това е много отрицателният първоначален опит, който кара много хора да използват нова рамка или да я възприемат на първо място и много малко рамки вършат добра работа, като помагат на новите потребители в тази първоначална пречка.
В PHP имаме и някои рамки, които всъщност не са рамки по начина, по който обикновено използвам думата. Имаме някои прекрасни рамки за компоненти; колекции от библиотеки, предназначени да се използват по желание и да играят добре заедно, като Zeta Components (преди това eZ Components) и Symfony Components (виждали ли сте сайта им? Те печелят наградата за най-добро произведение на изкуството!). Най-доброто и най-недоизпираното от тях, разбира се, са собствените предложения на PEAR и PECL на PHP - те по някакъв начин се забравят в този смел нов свят на рамки.
Микрорамки
Микрорамките са нова тенденция в PHP; това са суперлеки предложения, които просто ви помагат да слепите нещата по-бързо. Добър пример е Slim, който е много бърз и лесен за използване и разбира понятия RESTful. Тя се основава на идеята за „маршрути“, които са URL шаблони. Регистрирате маршрут и отправяте обратно повикване, което трябва да се извика, когато се поиска този URL адрес.
Повечето разработчици на PHP приемат рамка и се придържат към нея, или могат да използват една на работа и друга за своето хоби или проекти с отворен код. Има малко консенсус относно "най-добрата" рамка, която да се използва, така че всеки просто се придържа към това, което знае и резултатът е паралелно разработване на огромен брой рамки! Обичам да имам избор, от който да избирам, но споменах ли, че всички те са също толкова лоши, колкото един на друг?
Ако познавате Zend Framework, в крайна сметка се описвате като разработчик на Zend Framework; не би ви било удобно да пишете в друга рамка, докато не сте имали възможност да се справите с нея и вероятно не помните много от необработените PHP функции за нещата, ако не ги използвате често. Тази идея, че сме се превърнали в специфични за рамки разработчици, работещи само върху слоеве на абстракция, е малко странна за PHP. В крайна сметка това е езикът "за решаване на уеб проблема". Написано е на C и само по себе си е бърз, лек език ... при условие, че не чакате да стартира голям процес на стартиране на рамката! От този контекст възникна Манифестът на MicroPHP, написан от човек, когото наричаме Funkatron (въпреки че наистина се казва Ед Финклер). Това е поредица от изявления, в които се казва, че е добре да се изграждат редица оперативно съвместими малки модули, че по-големият не е по-добър и че наистина животът е твърде кратък за Java - дори ако е написан на PHP.
