Задаволены
Спытайце мяне, які фрэймворк выкарыстоўваць, і, напэўна, у мяне будзе сварлівы момант бабулькі і скажу вам, што ўсе фреймворкі такія ж дрэнныя, як адзін з адным. Што зусім не азначае, што ўсе яны дрэнныя, але ў 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) і Symfony Components (вы бачылі іх сайт? Яны атрымліваюць узнагароду за лепшыя творы мастацтва!). Самае лепшае і недастаткова праспяванае - гэта, вядома, уласныя прапановы PEAR і PECL ад PHP - яны неяк забываюцца ў гэтым адважным новым свеце рам.
Мікрарамкі
Мікрарамкі - гэта новая тэндэнцыя ў PHP; гэта звышлёгкія прапановы, якія проста дапамагаюць хутчэй злучыць рэчы. Добрым прыкладам з'яўляецца Slim, які вельмі хуткі і просты ў выкарыстанні і разумее паняцці RESTful. Ён заснаваны на ідэі "маршрутаў", якія з'яўляюцца шаблонамі URL. Вы рэгіструеце маршрут і даяце зваротны выклік, які павінен быць выкліканы пры запыце гэтага URL.
Большасць распрацоўшчыкаў PHP прымаюць рамкі і прытрымліваюцца іх, альбо яны могуць выкарыстоўваць адзін на працы, а другі для свайго хобі альбо праектаў з адкрытым зыходным кодам. Існуе мала адзінага меркавання наконт "лепшага" фреймворка, таму кожны проста прытрымліваецца таго, што ведае, і вынікам гэтага з'яўляецца паралельнае развіццё велізарнай колькасці фрэймворкаў! Мне падабаецца выбіраць, але ці згадваў я, што ўсе яны такія ж дрэнныя, як і адзін аднаго?
Калі вы ведаеце Zend Framework, у выніку вы апісваеце сябе распрацоўшчыкам Zend Framework; вам было б не камфортна пісаць у іншым фрэймворку, пакуль у вас не было магчымасці разабрацца з гэтым, і вы, напэўна, не памятаеце многія зыходныя функцыі PHP для рэчаў, калі не часта іх выкарыстоўваеце. Гэта ідэя пра тое, што мы сталі распрацоўшчыкамі, якія адносяцца да фрэймворкаў, і працуем толькі над пластамі абстракцыі, для PHP трохі дзіўная. У рэшце рэшт, гэта мова "для вырашэння Інтэрнэт-праблемы". Ён напісаны на C і сам па сабе з'яўляецца хуткім, лёгкім мовай ... пры ўмове, што вы не чакаеце запуску вялікага фреймворка! З гэтага кантэксту паўстаў Маніфест MicroPHP, напісаны чалавекам, якога мы называем Функатрон (хаця яго сапраўды завуць Эд Фінклер). Гэта шэраг заяў, у якіх гаворыцца, што добра стварыць шэраг маласумяшчальных невялікіх модуляў, большы - не лепш, і сапраўды, Java занадта кароткая - нават калі яна напісана на PHP.
