Application и Context в Bitrix D7: где живёт приложение и где данные текущего хита

Две «точки опоры»: приложение и хит

В ядре main разделение между «долго живущими» ресурсами и данными конкретного обращения к сайту явное. Класс Bitrix\Main\Application — это фасад к сервисам, которые существуют на протяжении работы процесса PHP: подключение к базе, кеш, пути к документ-корню и связанным каталогам. Объект Bitrix\Main\Context, наоборот, описывает один HTTP- или CLI-прогон: что пришло в запросе, что ответим клиенту, какие параметры окружения у этого захода.

Так меньше путаницы с $GLOBALS: сначала ищете фабричную точку Application::getInstance(), когда нужно «инфраструктурное»; когда важно «что именно пользователь отправил прямо сейчас» — опираетесь на Context::getCurrent().

Application: ресурсы, общие для сайта

Через синглтон приложения достаются соединения, таймзоны, кеширующие директории и документ-корень. Это то, что обычно не меняется от одной строки пользовательской формы к другой, пока живёт ваш скрипт.

use Bitrix\Main\Application;

$portal = Application::getInstance();
$filesystemRoot = Application::getDocumentRoot();
$dataLink = Application::getConnection();

// при необходимости — второе соединение по имени в .settings.php
$archiveLink = Application::getConnection('archive');

Не стоит плодить «своих» обёрток вокруг getInstance() без причины: ядро и так синхронизирует состояние; лишний слой только усложнит отладку.

Context: срез запроса, ответ и сервер

Контекст можно получить от приложения или статическим методом текущего хита:

use Bitrix\Main\Application;
use Bitrix\Main\Context;

$hit = Application::getInstance()->getContext();
// эквивалентно короткой форме
$hit = Context::getCurrent();

$inbound = $hit->getRequest();
$daemon = $hit->getServer();
$siteMarker = $hit->getSite();
$tongue = $hit->getLanguage();

getSite() и getLanguage() часто нужны до построения шаблонов: например, чтобы подключить нужный словарь или выбрать мультирегиональную ветку данных.

Ветка HttpRequest: параметры без ручной сборки суперглобалей

HttpRequest объединяет GET, POST, файлы и куки. Для простых ключей можно обращаться и как к массиву, но предпочтительнее явные методы: так проще читать намерение в код‑ревью.

$inbound = Context::getCurrent()->getRequest();

$needle = $inbound->get('needle');           // query или body
$segment = $inbound->getQuery('segment');
$payload = $inbound->getPost('payload');
$banner = $inbound->getFile('banner');
$sticky = $inbound->getCookie('sticky_sess');

$looksLikeAjax = $inbound->isAjaxRequest();
$adminUi = $inbound->isAdminSection();
$pathUserTyped = $inbound->getRequestUri();
$pageScript = $inbound->getRequestedPage();

Проверяйте содержательно: AJAX-эвристики иногда нужно дополнять собственными заголовками, если фронтенд их меняет.

Server: аккуратный доступ к переменным окружения

Обёртка Bitrix\Main\Server читает $_SERVER и даёт методы вида getDocumentRoot(), getHttpHost(), чтобы не рассыпать ключи строками по коду агента.

$daemon = Context::getCurrent()->getServer();

$publicTree = $daemon->getDocumentRoot();
$coreTree = $daemon->getPersonalRoot();
$hostLabel = $daemon->getHttpHost();
$forwardedProto = $daemon->get('HTTP_X_FORWARDED_PROTO');

Практические заметки

• В фоновых сценариях (агенты, cron) часть HTTP-методов контекста бессмысленна — проверяйте окружение до логики, завязанной на куки.
• Для тестов подменяйте контекст через API ядра, а не переписывайте суперглобалы напрямую.
• Дважды вызывать Application::getInstance() дёшево: возвращается один и тот же экземпляр; тяжёлые операции — в сервисах, а не в обёртках вокруг геттеров.

Кратко

Application — про устойчивые сервисы процесса; Context — про конкретный запрос. Запомните пару импортов и короткую цепочку Context::getCurrent()->getRequest() / getServer(), и большинство обращений к «окружению Битрикс» станет предсказуемым.