Статьи

Framework-системы

Framework… Когда я слышу это слово, меня переполняет целая масса эмоций.

Что такое framework??? Это вопрос, на который еще не было дано должного и исчерпывающего ответа. Мою позицию подтверждает окружающая действительность. Ведь куда не посмотришь везде framework’и, а остановить свой взгляд на чем-то конкретном и не получается. Есть отличная литература, в которой рассматривается архитектура подобных систем, но четких ответов на интересующие вопросы нет. Каждый волен думать и поступать, так как ему хочется.
 
Мне же кажется, что обсуждение систем подобного плана надо вести в другом ракурсе. В форуме мне не раз указали на такие вещи как programming pattern и прочее. Да, это все хорошо. И в принципе без этого теперь немыслима ни одна каркасная система.
Но мы с вами говорим не о том. Рассмотрение таких фундаментальных вещей как MVC, singleton, ORM, которые находят прямое применение во framework’ах - это тема, как минимум, для одной книги и нельзя сказать, что маленькой. Да и надо ли этим заниматься?
 
По этой тематике существует немалое количество качественной литературы. Да, реализация этих технологий тоже, порой, нелегкое дело. Но ведь мы с вами, на самом деле, не сделали и более простых вещей. А именно ядра этой системы. Если вы работали с какими-то конкретными framework системами, то задайтесь вопросом: «А где в моей framework системе ядро?». Сможете ли вы дать четкий и ясный ответ на этот вопрос? В большинстве случаев вряд ли. Почему? В одном форуме было дано такое определение framework системе: «это обычно просто набор стандартных библиотек». С технологической точки зрения примерно так все и обстоит. Но, скажите мне, тогда и PEAR – это framework система? Я так не считаю. Возможно, вы уже задались вопросом: «А зачем вообще нужно ядро как таковое»? Давайте
подумаем…
 

А как должно быть? 

Конечно же, мои слова не претендуют на роль последней истины – это было бы слишком самоуверенно с моей стороны. Но я хочу изложить свой взгляд на порядок вещей в нашем вопросе.
 
Framework-система – это не просто набор стандартных библиотек. Это система, которая определяет некоторые стандарты кодирования и обладает интерфейсом работы с модулями.
 
Модули – это ключевое понятие для CMF системы! Ядро обладает лишь системной функциональностью и даже не подозревает о том, что такое базы данных или паттерн MVC. Вся необходимая функциональность реализуется в модулях. Зачем это надо? Поймите меня правильно, я люблю MVC, я уважаю XML и все XML-подобное и не имею ничего против множества других полезных технологий. Но иногда мне нужно писать чистый PHP код без контроллеров, модели, отображения и всех прочих благ, которые в большинстве других
случаев, очень ценю. Иногда у меня возникает необходимость писать целые приложения без использования паттерна MVC или шаблонизатора как такового. Например, группа скриптов для работы с графиками (построение графиков по данным, по функциям) или с изображениями (генерирование картинки предпросмотра с маленьким разрешением и сохранение ее в кэше сервера). Поэтому я хочу иметь под рукой такую систему, от которой я бы смог отключить все ненужное и подключить все нужное одним взмахом руки над
клавиатурой. И в итоге получить приложение максимально эффективное по соотношению удобство программирования/быстродействие (а как вы знаете, эти величины находятся в обратно-пропорциональной зависимости).
 
К сожалению многие framework системы этого не позволяют, так как данная функциональность (вроде интерфейса MVC паттерна или интерфейса к БД) в них «вшита». Если быть точнее, то система как раз и заключается в этой функциональности и не существует сама по себе. Для реализации же того, о чем я говорю, необходимо абстрактное модульное ядро. Ядро, загрузчик, модуль и приложение - вот ключевые компоненты системы.
Проведите аналогию с родственными терминами из теории Операционных Систем и, возможно, вам многое станет яснее.
 
Я пришел к пониманию того, что framework система должна обладать хорошо выраженной структурой с централизованным управлением с помощью этого самого ядра. Ядро может выполнять разные функции, но главная из них коммуникативная! На основании API этого ядра должна создаваться вся остальная функциональность. Это в некоторой мере облегчает создание более высокоуровневых компонентов, так как определенная функциональность уже
выполняется ядром. К этой функциональности можно отнести, например, функции обработки ошибок и работы с конфигурационным хранилищем.
 

Проблемы отрасли 

Да. У этой отрасли инженерного знания, конечно же, есть проблемы. И вы их, наверное, хорошо понимаете. Отсутствие хорошей теоретической информации именно по построению ядра таких систем, а не высокоуровневых компонентов. Наверное, это обусловлено тем, что та интегрирующая (коммуникативная) функция ядра, о которой мы говорим, почти заканчивается на операторе «include».
 
Однако надо помнить, что «качественное» ядро должно уметь и много другого. Например, оно должно обладать удобными механизмами генерирования URL’ов. Все эти вопросы остаются на усмотрение программиста. Наверное, это и есть самое страшное.
Еще одна проблема, которую я уже высказывал – это неверное, на мой взгляд, понимание задач. Например, из всех мною виденных framework-систем, только несколько перехватывали ошибки времени выполнения. Разработчики зря обходят этот вопрос стороной. Ведь PHP предоставляет отличные средства для отладки. Для примера взгляните на отладочную информацию, которую генерирует моя framework-система в случае исключительной ситуации. С точки зрения средств языка – ничего экстраординарного.
 
Необходимо рассматривать framework-систему как «черный ящик», о задачах которого ничего неизвестно. И наращивать функциональность слоями - это способствует модульности системы и более низкому уровню связанности модулей.
 

Выводы

Это очень тяжелая тема. И я вам скажу мое мнение по поводу того, почему она такая тяжелая. Отнюдь не потому, что люди не могут применять паттерн MVC или уровень абстракции от БД. Она тяжелая потому, что framework-система определяет стиль кодирования, который нам, иногда, так не хочется менять (если только не мы
сами его придумали). Она тяжелая потому, что как я считаю, framework-систему легче написать самому для себя, так же как легче самому составить распорядок своего дня, потому что никто не сделает это лучше вас, так как этот «кто-то» не знает СТИЛЯ вашей жизни. Тем более, что написание основы такой системы - дело, в принципе, довольно не сложное и не должно занять много времени.
 
Еще одним очень важным моментом является документация.
Документация CMF системы – это ее жизнь. Без качественной документации система не представляет никакой ценности ни для кого, и через определенный промежуток времени даже для ее разработчика. Кто-то уже высказал идею о том, что документацию framework-системы надо писать раньше, чем саму систему. Именно этими правилами я руководствовался при создании своей framework-системы.
 
Я думаю, что рано или поздно мы создадим достаточно хорошую framework-систему, которая устроит если не всех, то большинство. И тогда в наш мир ворвется еще одна революционная
вещь сродни .NET Framework или Delphi VCL (а ведь это тоже в определенной степени framework-система).

Остается только работать и верить.

=====
Автор: Денис Баженов
PHP Inside - www.phpinside.ru