Содержание
Спросите меня, какой фреймворк использовать, и у меня, вероятно, будет момент сварливой старушки, и я скажу вам, что все фреймворки так же плохи, как друг друга. Это не означает, что все они плохие, но в 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 (вы видели их сайт? Они получают награду за лучшую иллюстрацию!). Лучшее и наиболее подходящее из них - это, конечно, собственные предложения PHP PEAR и PECL - почему-то они забываются в этом дивном новом мире фреймворков.
Микрофреймворк
Микрофреймворки - это новая тенденция в PHP; это сверхлегкие изделия, которые просто помогают быстрее склеивать предметы. Хорошим примером является Slim, очень быстрый и простой в использовании, понимающий концепции RESTful. Он основан на идее «маршрутов», которые представляют собой шаблоны URL. Вы регистрируете маршрут и даете обратный вызов, который должен вызываться при запросе этого URL-адреса.
Большинство разработчиков PHP берут на вооружение структуру и придерживаются ее, или они могут использовать одну на работе, а другую для своих хобби или проектов с открытым исходным кодом. Нет единого мнения о «лучшей» структуре для использования, поэтому все просто придерживаются того, что знают, и результатом является параллельная разработка огромного количества фреймворков! Мне нравится, когда есть из чего выбирать, но упоминал ли я, что все они так же плохи, как и друг друга?
Если вы знакомы с Zend Framework, вы в конечном итоге назовете себя разработчиком Zend Framework; вам было бы неудобно писать в другом фреймворке, пока у вас не будет возможности разобраться с ним, и вы, вероятно, не помните многие необработанные функции PHP для вещей, если не используете их часто. Идея о том, что мы стали разработчиками конкретных фреймворков, работая только над уровнями абстракции, немного странна для PHP. В конце концов, это язык «решения веб-проблемы». Он написан на C и сам по себе является быстрым и легким языком ... при условии, что вам не нужно ждать, пока запустится большой процесс начальной загрузки фреймворка! Из этого контекста возник Манифест MicroPHP, написанный человеком, которого мы зовем Фанкатроном (хотя на самом деле его зовут Эд Финклер). Это серия утверждений, говорящих о том, что можно создавать ряд совместимых небольших модулей, что больше - не лучше, и что на самом деле жизнь Java слишком коротка, даже если она написана на PHP.
