Структура или обработка в 1С: когда хватит контейнера, а когда нужен объект

16 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

Что вы реально сравниваете

Структура и обработка в 1С — это объекты разного класса. Сравнивать их «в лоб» — то же самое, что выбирать между блокнотом и текстовым редактором: оба хранят текст, но решают разные задачи.

• Структура — контейнер пар «ключ-значение», встроенный тип языка. Создаётся одной строкой, не требует места в конфигурации, не имеет своих процедур и не реагирует на события.
• Обработка — полноценный объект конфигурации с модулем, реквизитами, табличными частями, возможностью иметь формы. Внешняя обработка живёт отдельным файлом, встроенная — частью конфигурации. Имеет своё состояние, события, возможность выполняться на сервере и на клиенте.

Когда коллега говорит «возьми структуру» — он имеет в виду «не плоди сущности, передавай параметры лёгким контейнером». Когда говорит «нужна обработка» — «у тебя задача со своей логикой и состоянием, не пытайся всё уложить в контейнер».

Когда что брать

Как это выглядит в коде

Структура как контейнер параметров

// Передача семи параметров расчёта одной структурой
ПараметрыРасчёта = Новый Структура;
ПараметрыРасчёта.Вставить("Контрагент", Контрагент);
ПараметрыРасчёта.Вставить("Договор", Договор);
ПараметрыРасчёта.Вставить("ДатаНачала", ДатаНачала);
ПараметрыРасчёта.Вставить("ДатаОкончания", ДатаОкончания);
ПараметрыРасчёта.Вставить("УчитыватьАвансы", Истина);
ПараметрыРасчёта.Вставить("Округление", 2);
ПараметрыРасчёта.Вставить("Валюта", Валюта);

Результат = РассчитатьПоПараметрам(ПараметрыРасчёта);

Главное преимущество структуры в роли контейнера параметров — добавление восьмого параметра не ломает сигнатуру процедуры. Просто появляется новый ключ, старые места вызова не трогаются. На команде из трёх разработчиков это экономит часы споров о порядке аргументов.

Обработка как самостоятельный объект

Когда задача обрастает логикой — кэшем уже посчитанных значений, проверкой прав, формированием журнала событий — попытка передавать всё структурами превращается в семиэтажную пирамиду «структура внутри структуры». Это сигнал, что пора заводить обработку:

// В клиентском или серверном коде — создание объекта обработки
Калькулятор = Обработки.РасчётЗадолженности.Создать();
Калькулятор.УстановитьПараметры(Контрагент, Договор, ДатаНачала, ДатаОкончания);
Калькулятор.ВключитьКэш();
Результат = Калькулятор.Рассчитать();

Здесь объект живёт между вызовами, накапливает кэш, может предоставлять промежуточные результаты — то, что в структуре пришлось бы передавать с каждым вызовом и пересобирать.

Производительность

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

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

Самая дорогая ошибка — заменять обработку на структуру ради «производительности», когда задача честно содержит логику и состояние. На бенчмарке цифры красивые, в проде через полгода код превращается в «структура с десятью ключами, два из которых — снова структуры, а три — массивы». Сопровождать это нельзя. Производительность нужно мерить под реальную задачу, а не под микро-тест.

Чек-лист выбора

1. Что я передаю — только данные (значения полей) или объект со своим поведением?
2. Сколько раз я буду переиспользовать этот контейнер? Если один раз — точно структура.
3. Нужно ли мне состояние между вызовами? Если да — обработка.
4. Передаются ли данные через клиент-сервер? Если да — структура (обработка не сериализуется привычным образом).
5. Будет ли этот код раздаваться клиентам отдельно от конфигурации? Если да — внешняя обработка.
6. Может ли список параметров вырасти? Если да и сильно — структура, потому что добавление ключа не ломает сигнатуру.
7. Есть ли в сценарии формы, отчёты или табличные части? Если есть — обработка, структура не предназначена для UI.

Типичные ошибки

• «Передам всё одной структурой, чтобы не плодить параметры». Сначала контейнер на пять ключей, через месяц — на двадцать пять. Половина из них используется в одном вызове из десяти, читатель кода теряется в том, что обязательно, а что опционально. Решение — разбить на несколько структур с понятными ролями или завести обработку с явными методами.
• «Обработка ради двух процедур». Завели объект конфигурации, инициализация при каждом вызове, в модуле — две процедуры на 15 строк каждая. Это случай, когда обычная функция в общем модуле справится за 5% накладных. Обработка нужна для задач с состоянием, не для группировки функций.
• «Унифицируем — везде структуры». На «структурном» проекте через год обработки появляются всё равно — где-то нужен кэш, где-то форма для пользователя. Получается смешанная архитектура без правил. Лучше с самого начала договариваться: структура — для передачи параметров, обработка — для подсистем со своим состоянием.
• «Не проверил по сценарию клиент-сервер». Структуру с примитивными типами на сервер передадите без проблем. Если внутри структуры — ссылка на объект, который существует только на клиенте, — на сервере получите ошибку при обращении. Проверяйте состав структуры, если переходите границу.
• «Бенчмарк показал — значит, верно». Микро-тест на голой инициализации даёт цифры, далёкие от боевого сценария. Тестируйте на реалистичных данных и реалистичном количестве вызовов, иначе ускорение на бумаге обернётся новым кодом, который никто не сопровождает.