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