Почему в типовых конфигурациях 1С (ERP, УТ 11) классификаторы заполняются через гигантские функции в коде, а не через макеты?

Программист 1С:ERP Управление предприятием IT и автоматизация бизнеса
← На главную

Разработчики, работающие с крупными решениями на платформе 1С:Предприятие 8.3, такими как ERP Управление предприятием 2, Управление торговлей 11 или Комплексная автоматизация, часто сталкиваются с феноменом, который вызывает недоумение: наличие функций с тысячами строк однотипного «хардкода». Особенно ярко это проявляется в справочнике УпаковкиЕдиницыИзмерения. Рассмотрим причины такого архитектурного решения, разберем его плюсы и минусы, а также выясним, стоит ли использовать подобные приемы в собственной практике.

Анализ ситуации: функция ПолучитьДанныеКлассификатора

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

Проанализируем пример кода, который часто встречается в подобных модулях:


Функция ПолучитьДанныеКлассификатора() Экспорт
    
    Данные = Новый ТаблицаЗначений;
    Данные.Колонки.Добавить("Код", Новый ОписаниеТипов("Строка",,,, Новый КвалификаторыСтроки(3)));
    Данные.Колонки.Добавить("Наименование", Новый ОписаниеТипов("Строка",,,, Новый КвалификаторыСтроки(50)));
    // ... еще десятки колонок
    
    НоваяСтрока = Данные.Добавить();
    НоваяСтрока.Код = "003";
    НоваяСтрока.Наименование = "Миллиметр";
    // ... и так тысячи раз
    
    Возврат Данные;
    
КонецФункции

На первый взгляд, такой подход кажется нарушением всех правил «чистого кода». Однако за этим решением стоят конкретные технические и методологические соображения команды разработки фирмы «1С».

Почему используется программный код вместо макетов?

Традиционно для хранения статических данных классификаторов используются Макеты (в формате XML, MXL или JSON). Рассмотрим, почему в «тяжелых» конфигурациях предпочтение отдается программному наполнению:

  1. Компиляция в AST-дерево и скорость доступа. Когда платформа 1С загружает программный модуль, она компилирует его в абстрактное синтаксическое дерево (AST). Скомпилированный код функции ПолучитьДанныеКлассификатора уже находится в оперативной памяти сервера приложений. Вызов такой функции происходит практически мгновенно, в то время как чтение макета требует обращения к метаданным, извлечения двоичных данных, их парсинга (десериализации) и преобразования в объекты 1С.
  2. Автономность и надежность. Программный код является наиболее стабильной частью конфигурации. В редких случаях повреждения кэша метаданных или проблем с доступом к таблицам объектов, исполняемый код может оказаться более живучим, чем обращения к макетам. Это критично для процедур Обновления Информационной Базы (ОИБ), которые должны отработать в любых условиях.
  3. Удобство сравнения и объединения (Merge/Diff). Для систем контроля версий (таких как Git) или стандартного механизма сравнения/объединения конфигураций 1С, текстовый код гораздо «прозрачнее», чем двоичные данные макетов. Разработчик сразу видит, какие именно строки классификатора изменились, добавились или удались.
  4. Автоматическая кодогенерация. Важно понимать, что этот код не пишется вручную. Разработчики используют внутренние инструменты, которые преобразуют эталонные файлы классификаторов (например, из формата XLS или XML) в готовые листинги на языке 1С. Это исключает человеческий фактор при набивке данных.

Использование данных классификатора в системе

Рассмотрим, как эти данные используются на практике. Выясним, действительно ли система постоянно обращается к этим 5000 строкам. Проанализируем цепочку вызовов в типовом решении:


// В обработке подбора или при заполнении документа
ДанныеКлассификатора = Справочники.УпаковкиЕдиницыИзмерения.ЗаполнитьЕдиницыИзмеренияИзКлассификатора("796");

// Внутри модуля менеджера
Функция ЗаполнитьЕдиницыИзмеренияИзКлассификатора(Код) Экспорт
    ВсеДанные = ПолучитьДанныеКлассификатора(); // Тот самый гигантский вызов
    СтрокаКлассификатора = ВсеДанные.Найти(Код, "Код");
    // ... логика по созданию или обновлению элемента справочника
КонецФункции

Как мы видим, функция служит источником эталонных данных для сопоставления. Это особенно важно для работы Электронного документооборота (ЭДО). Когда в систему поступает входящий XML-файл (например, УПД), программа должна мгновенно определить, какой единице измерения соответствует код из файла. Наличие полного классификатора «под рукой» в коде гарантирует корректную работу сопоставления даже в абсолютно пустой базе.

Критический взгляд: недостатки «тяжелых» модулей

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

Рекомендации для разработчика

Проанализируем, стоит ли повторять этот опыт в своих разработках. Если перед вами стоит задача создать собственный классификатор (например, специфических отраслевых стандартов), придерживайтесь следующих правил:

  1. Если объем данных невелик (до 100-200 строк), использование макета типа Текстовый документ с данными в формате JSON или CSV будет оптимальным по балансу производительности и удобства поддержки.
  2. Если вы создаете тиражное решение, где критически важна автономность первого запуска без доступа к интернету, кодогенерация данных в модуль — вполне допустимый прием, одобренный практикой «1С».
  3. Используйте область #Область ОбновлениеИнформационнойБазы для выделения такого кода, чтобы другие разработчики понимали назначение этого блока и не пытались рефакторить его вручную.
  4. Помните про оптимизацию инициализации. Вместо того чтобы каждый раз заново строить таблицу значений из 5000 строк, рассмотрите возможность использования Повторного использования значений (кеширования) на время сеанса или вызова.

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

← На главную