В каких случаях использовать табличную часть объекта, а в каких таблицу значений на форме обработки

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При разработке обработок в системе 1С:Предприятие 8 программисты часто сталкиваются с выбором: создать полноценную Табличную часть (ТЧ) в метаданных объекта или ограничиться Таблицей значений (ТЗ), размещенной непосредственно в реквизитах формы. На первый взгляд может показаться, что визуально они идентичны, однако с точки зрения архитектуры, производительности и удобства поддержки между ними существует огромная разница. В этой статье мы подробно разберем, какой инструмент выбрать в зависимости от ваших задач.

Фундаментальное правило выбора

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

Рассмотрим подробнее, почему следование этому правилу критически важно для качества кода.

Преимущества использования Табличной части (ТЧ)

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

  1. Строгая типизация данных. Когда мы создаем ТЧ в метаданных, мы жестко задаем типы колонок. Платформа 1С берет на себя контроль за тем, чтобы в числовое поле не попала строка, а в поле ссылки — дата. В случае с ТЗ на форме типы часто определяются программно, что повышает риск возникновения ошибки Несоответствие типов в рантайме.
  2. Доступность в модуле объекта. Это один из самых важных аспектов. Табличная часть является частью данных самого объекта. Это означает, что внутри Модуля объекта вы можете обращаться к ней напрямую через ЭтотОбъект.ИмяТабличнойЧасти. Если же вы используете ТЗ на форме, вам придется передавать ее в модуль объекта как параметр при каждом вызове процедур, что загромождает код и усложняет отладку.
  3. Автоматическая генерация интерфейса. Для ТЧ платформа автоматически создает стандартные команды: "Добавить", "Скопировать", "Удалить", "Переместить вверх/вниз". При использовании ТЗ на форме многие из этих функций (например, перемещение строк) приходится реализовывать программно, создавая лишний код.
  4. Сохранение данных. Если в свойствах обработки включена опция "Сохранять значения", данные ТЧ могут сохраняться автоматически при закрытии формы и восстанавливаться при следующем открытии. С таблицей значений на форме этот фокус не пройдет — вам придется вручную писать алгоритмы сериализации данных в ХранилищеНастроек.

Посмотрим на пример того, как лаконично выглядит работа с ТЧ в модуле объекта:


Процедура РассчитатьИтогиНаСервере()
    // ТЧ доступна напрямую, не нужно передавать ее с формы
    Для Каждого СтрокаТЧ Из ТабличнаяЧастьТовары Цикл
        СтрокаТЧ.Сумма = СтрокаТЧ.Количество * СтрокаТЧ.Цена;
    КонецЦикла;
КонецПроцедуры

Когда уместно использовать Таблицу значений (ТЗ)

Несмотря на все плюсы ТЧ, существуют ситуации, когда без Таблицы значений не обойтись. Разберем их по шагам:

  1. Динамический состав колонок. Представьте, что вы пишете обработку для загрузки данных из Excel, где количество столбцов заранее неизвестно. В этом случае создать ТЧ в метаданных невозможно. Вам нужно программно формировать структуру ТЗ на форме.
  2. Временное хранилище "в памяти". Если таблица нужна только для промежуточных вычислений на сервере и ее не нужно показывать пользователю или хранить в контексте объекта, использование легкой ТЗ более оправдано, чем создание тяжелых метаданных.
  3. Отображение сложных результатов запросов. Иногда нужно вывести пользователю таблицу "только для чтения", которая собирается сложным запросом из разных источников. В этом случае ТЗ на форме выступает в роли удобного буфера.

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

Проблема передачи данных между контекстами

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

Рассмотрим пример правильного преобразования данных, если вам все же пришлось работать с ТЗ:


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

Интеграция с Библиотекой стандартных подсистем (БСП)

Если вы разрабатываете внешнюю обработку, которая будет подключаться к типовой конфигурации через механизм "Дополнительные отчеты и обработки", использование Табличной части становится практически обязательным. БСП активно использует метаданные объектов для автоматизации процессов. Например, при выгрузке данных или интеграции с другими подсистемами, механизмы БСП будут искать именно Табличные части. Если ваши данные лежат в "самодельной" ТЗ на форме, стандартные механизмы их просто "не увидят".

Выводы и рекомендации

Подводя итог, можно составить краткий чек-лист для принятия решения:

Помните, что чистота кода и следование стандартам разработки 1С значительно упрощают дальнейшую поддержку вашего программного продукта другими разработчиками. Использование ТЧ там, где это возможно — это признак профессионального подхода к проектированию систем.

← На главную