Развитие платформы «1С:Предприятие 8.3» принесло разработчикам мощный инструмент — расширения конфигурации. Однако до сих пор не утихают споры о том, стоит ли полностью отказываться от привычных внешних обработок или классического изменения типовой конфигурации. В этой статье мы подробно проанализируем возможности расширений, разберем их влияние на поддержку и производительность системы, а также выясним, в каких ситуациях они являются незаменимыми, а в каких — могут стать «бомбой замедленного действия».
Для начала определимся, что расширение — это вспомогательная конфигурация, которая накладывается на основную в момент запуска сеанса. В отличие от внешних обработок, расширение позволяет глубоко интегрироваться в логику системы. Проанализируем ключевые возможности:
Рассмотрим пример с доработкой печатной формы (ПФ), например, УПД. Если создавать внешнюю печатную форму для УПД в «1С:Бухгалтерии», нам придется выносить в обработку тысячи строк кода (около 3-4 тысяч), отвечающих за формирование данных. С расширением мы можем просто перехватить одну процедуру формирования макета, внести точечное изменение и оставить остальную логику на типовых механизмах. Это экономит часы работы программиста.
Для модификации логики в расширениях используются аннотации. Разберем, какие из них наиболее предпочтительны для стабильной работы системы:
Проанализируем пример использования &ИзменениеИКонтроль. Платформа визуально подсвечивает изменения, и если типовой код был переписан вендором, расширение просто не применится, выдав предупреждение, что гораздо лучше, чем «тихая» работа с ошибками.
&ИзменениеИКонтроль("СформироватьЗаголовок")
Процедура Расш1_СформироватьЗаголовок(Параметры)
// #Вставка
Если Параметры.Свойство("ОсобыйСтатус") Тогда
Параметры.Заголовок = "Специальный документ";
КонецЕсли;
// #КонецВставки
// ... здесь идет типовой код, который контролируется платформой
КонецПроцедуры
Добавление новых реквизитов и табличных частей через расширения — это вопрос, требующий особого внимания. Выясним, как это устроено в СУБД. При добавлении реквизита в расширение, платформа создает в SQL-базе дополнительную таблицу с суффиксом X1. При каждом запросе происходит соединение (JOIN) основной таблицы и таблицы расширения.
Важный риск: Если расширение будет удалено из базы, все данные, хранящиеся в его реквизитах, будут безвозвратно удалены вместе с таблицами X1. Поэтому для критически важных данных стратегически правильнее добавлять реквизиты в основную конфигурацию, даже если это потребует снятия объекта с поддержки. Расширения же идеально подходят для временных «заплаток» или второстепенных данных.
Существует миф, что расширения полностью избавляют от проблем при обновлении. Это не так. Рассмотрим ситуацию: мы расширили форму документа. В новом релизе 1С полностью переделала эту форму, изменив состав элементов. Наше расширение может либо «отвалиться», либо отображать некорректно работающие кнопки.
Чтобы минимизировать проблемы, придерживаемся следующих правил:
ПриСозданииНаСервере.Проанализируем ситуации, когда расширения использовать нельзя или неудобно:
Посмотрим на итоговое сравнение инструментов:
Внешние обработки:
.epf).Расширения:
Выясним, какой инструмент выбрать в конкретном случае. Если задача заключается в создании новой печатной формы, которая не требует глубокого перестроения алгоритмов формирования данных, — выбираем внешнюю печатную форму (ВПФ). Если же нам нужно изменить поведение кнопки на форме, добавить проверку при проведении или внедрить новый регистр сведений, по которому должен двигаться типовой документ — расширение будет лучшим выбором.
Для крупных проектов мы рекомендуем использовать гибридный подход: хранить структуру данных в основной конфигурации, а логику и интерфейсные доработки выносить в расширения. Это обеспечит максимальную стабильность данных и относительную легкость обновлений.