При разработке обработок в системе 1С:Предприятие 8 программисты часто сталкиваются с выбором: создать полноценную Табличную часть (ТЧ) в метаданных объекта или ограничиться Таблицей значений (ТЗ), размещенной непосредственно в реквизитах формы. На первый взгляд может показаться, что визуально они идентичны, однако с точки зрения архитектуры, производительности и удобства поддержки между ними существует огромная разница. В этой статье мы подробно разберем, какой инструмент выбрать в зависимости от ваших задач.
Проанализируем основное правило, которым руководствуются опытные разработчики: выбор зависит от определенности структуры. Если на этапе разработки (в Конфигураторе) вам точно известен состав колонок и их типы, следует использовать Табличную часть. Если же состав колонок может меняться динамически в зависимости от действий пользователя или внешних данных, вашим выбором станет Таблица значений.
Рассмотрим подробнее, почему следование этому правилу критически важно для качества кода.
Использование Табличной части объекта "Обработка" дает ряд неоспоримых преимуществ, которые упрощают жизнь программисту и повышают надежность системы:
Несоответствие типов в рантайме.Модуля объекта вы можете обращаться к ней напрямую через ЭтотОбъект.ИмяТабличнойЧасти. Если же вы используете ТЗ на форме, вам придется передавать ее в модуль объекта как параметр при каждом вызове процедур, что загромождает код и усложняет отладку.ХранилищеНастроек.Посмотрим на пример того, как лаконично выглядит работа с ТЧ в модуле объекта:
Процедура РассчитатьИтогиНаСервере()
// ТЧ доступна напрямую, не нужно передавать ее с формы
Для Каждого СтрокаТЧ Из ТабличнаяЧастьТовары Цикл
СтрокаТЧ.Сумма = СтрокаТЧ.Количество * СтрокаТЧ.Цена;
КонецЦикла;
КонецПроцедуры
Несмотря на все плюсы ТЧ, существуют ситуации, когда без Таблицы значений не обойтись. Разберем их по шагам:
Проанализируем ситуацию с передачей данных. Важно помнить, что ТаблицаЗначений — это объект, который живет только на сервере. Для отображения её на форме используется тип ДанныеФормыКоллекция. Это накладывает свои ограничения на производительность при передаче больших объемов данных между клиентом и сервером.
Выясним причину, по которой многие разработчики жалуются на ТЗ при работе в управляемом приложении. При использовании Табличной части объекта, платформа оптимизирует передачу данных. Если же вы используете произвольную ТЗ на форме, при каждом вызове серверного метода происходит полная сериализация и десериализация этой коллекции, что может привести к заметным "тормозам" интерфейса при большом количестве строк.
Рассмотрим пример правильного преобразования данных, если вам все же пришлось работать с ТЗ:
&НаСервере
Процедура ЗаполнитьТЗНаСервере()
// Преобразуем ДанныеФормыКоллекция в реальную ТаблицуЗначений для обработки
ТЗ = РеквизитФормыВЗначение("ТаблицаНаФорме", Тип("ТаблицаЗначений"));
// Выполняем действия с таблицей
// ...
// Возвращаем результат обратно на форму
ЗначениеВРеквизитФормы(ТЗ, "ТаблицаНаФорме");
КонецПроцедуры
Если вы разрабатываете внешнюю обработку, которая будет подключаться к типовой конфигурации через механизм "Дополнительные отчеты и обработки", использование Табличной части становится практически обязательным. БСП активно использует метаданные объектов для автоматизации процессов. Например, при выгрузке данных или интеграции с другими подсистемами, механизмы БСП будут искать именно Табличные части. Если ваши данные лежат в "самодельной" ТЗ на форме, стандартные механизмы их просто "не увидят".
Подводя итог, можно составить краткий чек-лист для принятия решения:
Помните, что чистота кода и следование стандартам разработки 1С значительно упрощают дальнейшую поддержку вашего программного продукта другими разработчиками. Использование ТЧ там, где это возможно — это признак профессионального подхода к проектированию систем.