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