Можно ли выводить реквизиты на управляемую форму через точку и как это влияет на производительность?

← На главную

Среди разработчиков 1С давно укоренилось правило: «обращение через точку — это зло». Мы привыкли, что использование конструкций вида Объект.Контрагент.ИНН в программном коде приводит к получению всего связанного объекта из базы данных, что негативно сказывается на скорости работы системы. Однако когда речь заходит о проектировании интерфейса управляемой формы, ситуация меняется. Давайте подробно разберем, насколько допустимо выводить реквизиты через точку напрямую в элементы формы, как при этом ведет себя платформа и какие «подводные камни» могут встретиться на пути разработчика.

Механизм работы DataPath и оптимизация платформы

Для начала разберем главный миф: обращение через точку в поле данных (DataPath) элемента формы работает так же, как в коде на сервере. Это не совсем так. Рассмотрим подробнее, как платформа 1С:Предприятие 8.3 обрабатывает такие запросы.

Когда мы указываем в качестве пути к данным элемента формы путь через точку (например, Объект.Склад.ОтветственноеЛицо), система не выполняет стандартное обращение к объекту, которое мы привыкли видеть в серверном коде. Платформа анализирует структуру формы в момент её создания. Механизм DataPath позволяет системе составить оптимизированный запрос к базе данных. Вместо того чтобы вытягивать объект Склад целиком со всеми его реквизитами и табличными частями, платформа «подмешивает» к основному запросу формы только те конкретные поля, которые реально требуются для отображения.

Проанализируем ситуацию: если на форме выведен только ИНН контрагента через путь Объект.Контрагент.ИНН, то в SQL-запросе, который сформирует платформа, будет запрошено только поле ИНН из таблицы справочника контрагентов. Таким образом, «эффект точки» в интерфейсе значительно слабее, чем в коде.

Различия между формой объекта и динамическим списком

Важно понимать, что допустимость использования точек сильно зависит от контекста. Разберем два основных случая:

Форма объекта или реквизит типа Ссылка: Здесь использование одной-двух точек вполне оправдано. Поскольку форма отображает данные одного конкретного объекта, один дополнительный (даже неявный) LEFT JOIN в запросе не создаст ощутимой нагрузки на сервер БД. Это экономит время разработчика и избавляет от написания лишнего кода в процедуре ПриСозданииНаСервере.
Динамический список: А вот здесь использование точек в путях данных колонок крайне не рекомендуется. В динамическом списке данных много, и каждая точка превращается в неявное соединение таблиц на уровне СУБД. Если список содержит тысячи строк, а мы добавили 5 колонок через точки от разных справочников, производительность при листании, поиске и сортировке упадет в разы. В таких случаях правильнее изменить текст запроса динамического списка, явно прописав ЛЕВОЕ СОЕДИНЕНИЕ.

Проблема актуальности данных (кеширование)

Выясним причину, по которой опытные разработчики иногда всё же избегают этого механизма. Основная засада кроется в обновлении отображаемых данных. Посмотрим на жизненный цикл данных на форме. Если мы вывели Объект.Контрагент.Телефон, и в процессе работы с формой пользователь (или фоновое задание) изменит телефон в карточке контрагента, данные на нашей форме не обновятся автоматически.

Платформа считывает данные «через точку» в момент получения основной ссылки. Чтобы обновить это значение, пользователю придется либо переоткрыть форму, либо разработчику нужно будет вызвать метод ЭтаФорма.Обновить(). Однако вызов Обновить() — это тяжелая операция, которая перечитывает весь контекст, что может быть избыточным ради одного поля.

Если же мы меняем самого контрагента в поле Объект.Контрагент, платформа инициирует обновление связанных путей. В этот момент происходит неявный серверный вызов. Если таких полей на форме десятки, визуальный отклик интерфейса может стать «вязким», так как системе нужно подтянуть множество связанных данных за один раз.

Когда стоит использовать программный вывод данных?

Рассмотрим по шагам альтернативный подход, который считается «золотым стандартом» в высоконагруженных системах. Вместо использования точек в элементах формы, мы можем:

Создать отдельный реквизит формы (например, ИНН_Контрагента с типом Строка).
В событии ПриСозданииНаСервере заполнить его одним запросом вместе с остальными данными.
В событии КонтрагентПриИзменении программно обновлять этот реквизит, опять же используя точечный запрос к базе данных.

Пример кода для обновления данных без использования «точек» в интерфейсе:


&НаСервере
Процедура ОбновитьДанныеКонтрагентаНаСервере()
    // Используем запрос, чтобы избежать получения объекта целиком
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Контрагенты.ИНН КАК ИНН,
        |   Контрагенты.КПП КАК КПП
        |ИЗ
        |   Справочник.Контрагенты КАК Контрагенты
        |ГДЕ
        |   Контрагенты.Ссылка = &Ссылка";
    
    Запрос.УстановитьПараметр("Ссылка", Объект.Контрагент);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        ИНН_Контрагента = Выборка.ИНН;
        КПП_Контрагента = Выборка.КПП;
    КонецЕсли;
КонецПроцедуры

Такой подход гарантирует, что вы точно контролируете количество обращений к базе данных и объем передаваемого контекста между сервером и клиентом.

Особенности прав доступа и составных типов

Проанализируем еще один важный аспект — безопасность. Если путь к данным проходит через реквизит составного типа, или у пользователя нет прав на чтение связанного объекта, поведение системы может быть следующим:

Если тип реквизита однозначен, но прав нет — поле на форме будет просто пустым (или система выдаст ошибку доступа при открытии всей формы, в зависимости от настроек прав).
Если ссылка «битая» (Объект не найден), платформа корректно это обработает и не вызовет падения системы, просто отобразив пустое значение.
Важно помнить: поля, выведенные через точку, всегда работают в режиме Только просмотр. Вы не сможете редактировать ИНН контрагента прямо из формы документа, используя этот механизм. Платформа блокирует изменение данных «через владельца» для защиты целостности БД.

Итоги и рекомендации

Подведем итог нашему исследованию. Выводить реквизит через точку на управляемую форму — нормально в большинстве повседневных задач автоматизации. Это стандартный механизм платформы, который обладает встроенной оптимизацией запросов.

Однако придерживайтесь следующих правил, чтобы не создать проблем в будущем:

Для разовых справочных полей (ИНН, артикул, краткое описание) — смело используйте точку. Это быстро и удобно.
Для динамических списков — избегайте точек, используйте произвольные запросы.
Для критически важных полей, которые должны мгновенно обновляться при изменении в других сессиях — используйте программное заполнение и обработчики оповещений.
Для высоконагруженных форм (где выводится более 10–15 полей через точки) — лучше объединить получение данных в один компактный запрос на сервере и выводить их через реквизиты формы.

Таким образом, мы видим, что страх перед «точкой» на форме часто преувеличен, но понимание внутренней работы платформы позволяет использовать этот инструмент осознанно и эффективно.