Зачем в методах 1С (БСП) раздельно передаются параметры ЭтотОбъект и Объект?

При разработке и кастомизации конфигураций на платформе 1С:Предприятие 8.3 программисты регулярно сталкиваются с вызовами интерфейсных процедур из Библиотеки стандартных подсистем (БСП). Один из наиболее частых вопросов, вызывающий оживленные споры в сообществе, касается сигнатуры процедур вида УправлениеКонтактнойИнформацией.ПриСозданииНаСервере(ЭтотОбъект, Объект, ...). На первый взгляд кажется, что передача обоих параметров избыточна, ведь контекст формы ЭтотОбъект уже содержит внутри себя основной реквизит Объект. Однако за таким решением стоит строгая архитектурная логика. В этой статье мы подробно разберем, почему платформа и стандарты разработки требуют разделения этих понятий.

Разбор понятий: Что скрывается за ЭтотОбъект и Объект?

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

1. В модуле управляемой формы:
   • ЭтотОбъект — это системная переменная, которая возвращает саму форму (тип УправляемаяФорма). Это ваш холст, интерфейсная оболочка, содержащая элементы управления, команды, списки и методы визуального отображения.
   • Объект — это прикладные данные (тип ДанныеФормыСтруктура), выступающие в роли основного реквизита формы. Это программное представление сущности базы данных (например, документа или элемента справочника), с которой сейчас работает пользователь.
2. В модуле прикладного объекта (модуле справочника, документа, процесса):
   • ЭтотОбъект указывает непосредственно на сам прикладной объект базы данных (тип СправочникОбъект, ДокументОбъект и т.д.).
   • Переменная Объект в этом контексте по умолчанию отсутствует (если только разработчик не объявил её вручную, что считается грубым нарушением стандартов разработки).

Таким образом, в контексте управляемой формы (а именно там происходит инициализация интерфейса БСП) ЭтотОбъект и Объект — это принципиально разные сущности: Форма (интерфейс) и Данные (модель).

Исторический контекст: эволюция ЭтотОбъект в управляемых формах

Давайте сделаем небольшой экскурс в историю развития платформы «1С:Предприятие». До версии 8.3.3 в модуле управляемой формы встроенного свойства ЭтотОбъект не существовало вообще. Для обращения к контексту формы использовалось ключевое слово ЭтаФорма.

В те времена разработчики нередко использовали переменную ЭтотОбъект как локальную переменную для получения объекта базы данных через метод:

ЭтотОбъект = РеквизитФормыВЗначение("Объект");

Начиная с версии платформы 8.3.3 (при отключенном режиме совместимости), свойство ЭтаФорма было объявлено устаревшим, а ключевое слово ЭтотОбъект в модуле формы зарезервировано под саму управляемую форму. Это привело к строгому разделению: форма стала формой, а данные — данными.

Почему БСП требует передавать и форму (ЭтотОбъект), и данные (Объект)?

Рассмотрим по шагам ключевые архитектурные причины, по которым универсальные механизмы БСП (такие как подсистемы контактной информации, присоединенных файлов, свойств и дополнительных реквизитов) требуют раздельной передачи формы и данных.

1. Разделение зон ответственности (Паттерн MVC)

Проанализируем, как работает подсистема контактной информации при инициализации формы на сервере. Процедура БСП решает две принципиально разные задачи:

• Интерфейсная задача: БСП должна динамически (программно) создать на форме элементы управления — группы, поля ввода, декорации и кнопки для редактирования адресов или телефонов. Для этого подсистеме нужен доступ к коллекции элементов формы. Этот доступ она получает через первый параметр ЭтотОбъект (Форма).
• Задача обработки данных: БСП должна связать созданные поля ввода с конкретными путями к данным, чтобы пользователь мог изменять информацию, и она корректно записывалась в базу данных. Источником этих данных выступает второй параметр — Объект.

2. Универсальность и независимость от имени основного реквизита

Платформа 1С не обязывает разработчика всегда называть главный реквизит формы словом Объект. Имя основного реквизита зависит от типа формы и проектных решений:

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

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

3. Размещение нескольких независимых блоков данных на одной форме

Это самый мощный практический аргумент в пользу разделения параметров. Бывают ситуации, когда на одной форме необходимо одновременно отобразить и редактировать контактную информацию (или дополнительные реквизиты) сразу нескольких разных владельцев.

Рассмотрим классический пример из типовой конфигурации «1С:Управление торговлей 11». В форме элемента справочника «Партнеры» (если в программе отключен раздельный учет партнеров и контрагентов) на форму одновременно выводятся данные как самого Партнера, так и связанного с ним Юридического лица (Контрагента).

Посмотрим, как выглядит программная инициализация контактной информации в модуле формы партнера:

// СтандартныеПодсистемы.КонтактнаяИнформация
ДополнительныеПараметрыКИ = УправлениеКонтактнойИнформацией.ПараметрыКонтактнойИнформацией;
ДополнительныеПараметрыКИ.Вставить("ИмяЭлементаДляРазмещения", "ГруппаКонтактнаяИнформация");
ДополнительныеПараметрыКИ.Вставить("ПоложениеЗаголовкаКИ", ПоложениеЗаголовкаЭлементаФормы.Лево);

// Вызов 1: Отрисовываем и связываем КИ самого Партнера
УправлениеКонтактнойИнформацией.ПриСозданииНаСервере(ЭтотОбъект, Объект, ДополнительныеПараметрыКИ);

ДополнительныеПараметрыКИ.Вставить("ИмяЭлементаДляРазмещения", "ГруппаКонтактнаяИнформацияКонтрагента");
ДополнительныеПараметрыКИ.Вставить("ПоложениеЗаголовкаКИ", ПоложениеЗаголовкаЭлементаФормы.Лево);
ДополнительныеПараметрыКИ.Вставить("СкрываемыеВиды", ОбщегоНазначенияУТПовтИсп.МассивИсключаемыхВидовКИКонтрагентаДляВыводаВФормеПартнера);

// Вызов 2: Отрисовываем и связываем КИ связанного Контрагента на той же форме!
УправлениеКонтактнойИнформацией.ПриСозданииНаСервере(ЭтотОбъект, КонтрагентПартнера, ДополнительныеПараметрыКИ);
// Конец СтандартныеПодсистемы.КонтактнаяИнформация

Проанализируем этот код подробнее. Обратите внимание на два вызова метода ПриСозданииНаСервере:

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

Если бы система жестко привязывалась к реквизиту формы по умолчанию, реализовать подобный сценарий совмещенного вывода данных было бы невозможно без создания сложных «оберток» или дублирования форм.

Сводная таблица сравнения параметров

Для закрепления материала сопоставим ключевые характеристики анализируемых параметров в модуле управляемой формы:

Резюме

Разделение параметров на ЭтотОбъект (контекст формы) и Объект (контекст данных) в методах БСП — это не избыточность, а обдуманное архитектурное решение. Оно позволяет разработчикам платформы писать по-настоящему гибкий, универсальный и масштабируемый код подсистем, способный работать в формах любого назначения и выводить данные множества различных владельцев на едином пользовательском интерфейсе.