Садржај
Питајте ме који оквир да користим и вероватно ћу имати тренутак мрзовољне старице и рећи ћу вам да су сви оквири лоши једни од других. Што не значи да су сви тачно лоши, али у ПХП-у имамо незамисливо велики број оквира (обично се наводи као Н + 1, где је Н број ПХП програмера у свету), и сви су вероватно имали смисла особи која их је измислила.
Имати избор оквира је вероватно боље од покушаја да се користи само један оквир, без обзира на то шта сте тачно покушавали да направите, јер је онај „најбољи“ (по било којој мери „најбољи“). Овај одабир оквирних понуда значи да можете одабрати нешто што задовољава потребе пројекта, а то може бити чак и документовано. Оквири на било којој платформи заиста су ту да пруже структуру, модуле за вишекратну употребу и библиотеке и углавном избегавају све досадне и понављајуће задатке који се изводе израдом исте функције изнова и изнова. На пример, приликом изградње ЦМС-ова, нешто би требало да обради и потврди поља обрасца за мене; ако се препустим сам себи, можда пропустим нешто важно и много бих радије радио елементе сваког пројекта који јесу различит, него оне које су сваки пут исте!
Фулл-стацк оквири
Фулл-стацк оквири, као што је Зенд Фрамеворк, могу бити лепо место за почетак за програмере без пуно архитектонског искуства. Даје добру структуру на коју се може окачити нова апликација, а око ње постоји добар „екосистем“ - мноштво књига, водича и неке разумне документације. Ако покушавате да направите велику апликацију коју ће одржавати велики број људи, тада ће популарни, свеобухватни оквир вероватно бити добар избор, јер ће диктирати доста структуре и бити добро познат и разумљив.
Имати структуру која помаже у раздвајању је увек добро; рано у каријери сарађивао сам са некима врло млађи програмери и покушали су да их науче МВЦ (Модел Виев Цонтроллер) образац, који је у то време био релативно нов. Донели смо одлуку да користимо Смарти у слоју приказа; делом како би дизајнери могли лакше да раде са шаблонима, а делом тако да када је неко дошао до мог стола и рекао „како да радим Кс са Смарти?“ Могао бих да кажем „не ради Кс у погледу!“ (девет пута од 10, то је био одговор). Поседовање оквира помаже нам да пронађемо исто раздвајање у другим деловима наше апликације. Многи од њих подржавају интеграцију са предлошком као што је Смарти или мој нови фаворит Твиг, тако да те алате можете понети са собом било који оквир који одаберете.
Олакшати терет
Постоји пуно лакших оквира од Зенд Фрамеворк-а, на пример прилично радим са ЦодеИгнитер-ом. Да ли је свеобухватан и робустан као Зенд Фрамеворк? Не, није. Али као помоћни оквир за брзу изградњу апликације је користан. Генерално, оквири са мање функционалности „помоћника“ могу се лакше сналазити јер је много очигледније како комади иду заједно. У непознатом оквиру (за мене је то готово све), аутоматички битови отежавају рад и отклањање грешака.
Тај осећај „изгубљености у новом оквиру“ неизбежан је и крајње фрустрира; чак се и искусни програмер осећа као почетник када не зна како нешто функционише. Ако заиста немате среће, изабраћете оквир чији ће вам ИРЦ канал рећи да сте и ви идиот! То је врло негативно почетно искуство које многе људе на првом месту спречава да користе нови оквир или га усвоје, а врло мало оквира добро помогне новим корисницима у тој почетној препреци.
У ПХП-у имамо и неке оквире који заправо нису оквири на начин на који ја обично користим реч. Имамо неке дивне оквире компонената; колекције библиотека дизајниране да буду корисне по својој вољи и да се лепо играју заједно, као што су Зета Цомпонентс (раније еЗ Цомпонентс) и Симфони Цомпонентс (да ли сте видели њихов сајт? Добијају награду за најбоље уметничко дело!). Најбоље и најнеупеваније од њих је, наравно, ПХП-ова понуда ПЕАР и ПЕЦЛ - некако се оне забораве у овом храбром новом свету оквира.
Мицрофрамеворкс
Микрооквири су нови тренд у ПХП-у; ово су супер лагане понуде које вам само помажу да брже лепите ствари. Добар пример је Слим, који је врло брз и једноставан за употребу и разуме концепте РЕСТфул. Заснован је на идеји „руте“, што су обрасци УРЛ-а. Региструјете руту и дајете повратни позив који треба да се позове када се захтева тај УРЛ.
Већина програмера ПХП-а усваја оквир и држи га се, или би могао користити један на послу, а други за своје хобије или пројекте отвореног кода. Мало је консензуса око „најбољег“ оквира за употребу, па се сви држе онога што знају, а резултат је паралелни развој огромног броја оквира! Волим да имам избор који могу да бирам, али да ли сам споменуо да су сви подједнако лоши?
Ако знате Зенд Фрамеворк, на крају ћете се описати као програмер Зенд Фрамеворк-а; не би вам било пријатно да пишете у другом оквиру док не бисте имали прилику да се са тим позабавите и вероватно се не сећате многих сирових ПХП функција за ствари ако их не користите често. Ова идеја да смо постали програмери специфични за оквир, који раде само на слојевима апстракције, помало је чудна за ПХП. На крају крајева, ово је језик „за решавање веб проблема“. Написано је на Ц и сам по себи је брз, лаган језик ... под условом да не чекате да се покрене велики оквирни боотстрап процес! Из овог контекста је произашао манифест МицроПХП, који је написао човек кога зовемо Функатрон (иако се заиста зове Ед Финклер). Низ је изјава које кажу да је у реду изградити бројне интероперабилне мале модуле, да већи није бољи и да је заиста живот Јава прекратак - чак и ако је написан на ПХП-у.
