Изначально я думал, что ответом будет большое « Нет, вы в каменном веке ».
Затем все начало меняться.
Мышление сообщества PHP
Например, я встретил Илью Алшанецкого , участника ядра PHP, на конференции PHP в Барселоне в октябре. Он сказал, что не рассматривает рамки в своей работе. Я не знаю, имел ли он в виду процедурный подход или только избегал включения фреймворков в качестве внешнего кода, но это только начало.
Стоимость рамок
В те же дни я присутствовал на выступлении Маттео Ваккари на Webtech 2010 . Это было на итальянском языке, но перевод звучал бы как веб-программирование без фреймворка . Контекстом была платформа Java, где платформы даже более инвазивны, чем в PHP.
В этом выступлении я узнал о некоторых интересных моментах, которые часто упускаются из виду при рассмотрении принятия фреймворков, в восторге от надежды написать меньше кода.
- Кривая обучения и привязка : вам нужно некоторое время работать с фреймворком, чтобы привыкнуть к нему; тогда вам будет трудно вернуться, так как вы потратили много времени (что является деньгами) и строк кода в этой среде. Я разработал диссертацию бакалавра с помощью SMILA, Java-фреймворка для поисковых приложений, и половина времени ушла на то, чтобы заставить его работать.
- Обновление и управление версиями : фреймворки похожи на библиотеки, и их необходимо регулярно обновлять и встраивать в сборку или в репозиторий.
- Ошибки, ошибки, отсутствующие функции, которые нам сложно добавить, магические функции, которые мы хотели бы удалить. Фреймворки — это еще один уровень абстракции, который открывает новый путь для ошибок и ошибок.
Таким образом, как правило, стоимость интеграции библиотек недооценивается, и фреймворки не являются исключением.
Как интегрировать библиотеку
Первое, что вы делаете, когда интегрируете библиотеку, — это оборачиваете ее в интерфейс, с которым ваш код легко работать, и определяете только те функции, которые вы используете в этом Фасаде.
Это хороший способ сохранить изолированную библиотеку, далеко от ядра вашей кодовой базы, чтобы вы могли в будущем поменять ее на аналогичную в случае, если проект умирает или выбирает новые направления, которые вам совсем не нравятся.
Подвох в том, что вы не можете сделать это с помощью фреймворка. Каркас определяется как библиотеки, которые вам звонят, а не вы их вызываете . Например, в Zend Framework вы определяете контроллеры как
class MyController extends Zend_Controller_Action{ public function indexAction() {}}
и объект этого класса будет создан и вызван для вас. Это невероятно удобно для создания приложения с нуля, но его трудно изолировать. Хотя уровень абстракции над библиотекой — это просто пара интерфейса и класса, я никогда не видел, чтобы кто-то пытался абстрагировать контроллер, реализуя различные «драйверы контроллера». Лучшее, что мы можем сделать (в PHP) — это сделать контроллеры как можно меньше.
Каркасы — это универсальные средства, которые должны поддерживать множество различных вариантов использования.
Zend Framework, который на самом деле является гибридом, прост в использовании в качестве библиотеки: вы создаете объекты Zend_Locale, Zend_Translate или Zend_Filter и составляете их.
Но сторона фреймворка (в основном Zend_Controller) подталкивает к определению Zend_Locale и Zend_Translate как глобальных объектов, которые волшебным образом вмешиваются в вашу обработку ввода и вывода. Тестирование кода, включающего в себя фреймворк, — это кровавая баня, если только фреймворк не предоставит вам какую-то утилиту в качестве обходного пути для магических функций, таких как Zend_Test (которая отключает exits (), redirect и Zend_Session).
Это действительно круто? Для полноценного управления приложением в среде полно Singletons и глобального состояния (которые находятся в стадии доработки в Zend Framework 2.0), множество настроек и множество вопросов о том, как определять значения ini и с какими именами.
Структура папок также отличается от стандартной автозагрузки, но в некоторой степени является стандартом в приложении фреймворка (еще одна блокировка). Есть много различных соглашений, которым вы должны следовать — имена в верхнем и нижнем регистре, подчеркивания, camelCase и все в нижнем регистре.
И для чего? Например, поддержка нескольких путей для помощников представления, чтобы некоторые пути волшебным образом перезаписывали предыдущие. По вашему мнению, вы можете вызвать $ this-> url (), и будет отправлен правильный помощник вида Url.
Тебе это действительно нужно? Некоторые из нас делают, но это меньшинство. Я просто предоставил бы жестко запрограммированный список классов помощников вида, которые нужно вставить в мое представление (я знаю, что карты классов , вероятно, будут делать что-то подобное).
То же самое касается ресурсов, плагинов, элементов формы и декораторов; Zend_Form поддерживает фильтрацию, проверку, рендеринг, оформление, отображение групп … Я никогда не использую больше половины из них одновременно.
Каждая подвижная часть добавляет к сложности понимания того, как каркасные работы , и как это исправить , когда она ломается . В то же время, это мало что добавляет к разработчику, так как это общая реализация, которая в любом случае должна быть адаптирована к текущим потребностям.
Вывод
Подводя итог, фреймворк пытается спасти вашу работу, заставляя вас определять слишком сложную конфигурацию, которая должна учитывать все возможные варианты использования. Этот декларативный подход к созданию приложения не всегда превосходит программный, где вы строите графы объектов вручную.
Это причина, чтобы бросить рамки? Только если вы уже знаете, что вашему приложению не понадобится такая сложная архитектура. Но тем временем я буду продолжать делать свои контроллеры как можно меньше. Надеюсь увидеть ваше мнение в комментариях.