Зміст
Запитайте мене, який фреймворк використовувати, і я, мабуть, отримаю сварливий момент старенької жінки і скажу вам, що всі фреймворки такі ж погані, як один одного. Що не означає, що всі вони погані, точно, але в 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 (ви бачили їхній сайт? Вони отримують нагороду за найкращу ілюстрацію!). Найкраще і найбільш недоспіване з них - це, звичайно, власні пропозиції PHAR і PEAR та PECL - якимось чином вони забуваються в цьому сміливому новому світі фреймворків.
Мікрорамки
Мікрокаркаси - це нова тенденція в PHP; це надлегкі пропозиції, які просто допомагають швидше склеювати речі. Хорошим прикладом є Slim, який є дуже швидким і простим у використанні та розуміє поняття RESTful. Він базується на ідеї „маршрутів”, що є шаблонами URL-адрес. Ви реєструєте маршрут і здійснюєте зворотний дзвінок, який слід викликати, коли запитується ця URL-адреса.
Більшість розробників PHP приймають фреймворк і дотримуються його, або вони можуть використовувати один на роботі, а інший для своїх хобі чи проектів з відкритим кодом. Існує мало єдиної думки щодо "найкращого" фреймворку, тому кожен просто дотримується того, що знає, і результатом є паралельна розробка величезної кількості фреймворків! Мені подобається мати вибір на вибір, але чи я згадував, що всі вони такі ж погані, як один одного?
Якщо ви знаєте Zend Framework, тоді ви описуєте себе розробником Zend Framework; вам буде некомфортно писати в іншому фреймворці, поки ви не зможете з цим впоратись, і ви, мабуть, не пам’ятаєте багато необроблених функцій PHP для речей, якщо не часто їх використовуєте. Ця ідея про те, що ми стали конкретними розробниками, що працюють лише над шарами абстракції, для PHP є трохи дивною. Зрештою, це мова "для вирішення веб-проблеми". Він написаний на мові C і є швидким, легким мовою сам по собі ... за умови, що ви не чекаєте запуску великого фреймворкового процесу завантаження! З цього контексту вийшов Маніфест MicroPHP, написаний людиною, яку ми називаємо Funkatron (хоча його справді звуть Ед Фінклер). Це низка тверджень, які говорять про те, що це нормально, щоб створити низку взаємодіючих малих модулів, що більший не краще, і що насправді, життя занадто коротке для Java - навіть якщо це написано на PHP.
