Каждый разработчик 1С рано или поздно сталкивается с дилеммой: где именно реализовать новый функционал — будь то отчет, печатная форма, заполнение объекта или сложная обработка данных. Стоит ли подключать решение как внешнее, внедрить его непосредственно в основную конфигурацию или воспользоваться механизмом расширений? Этот вопрос становится особенно острым, когда база данных снята с поддержки или находится на этапе активного рефакторинга несколькими разработчиками одновременно.
В этой статье мы подробно проанализируем все три подхода, взвесим их сильные и слабые стороны, разберем влияние на производительность системы и поможем вам сформировать четкий алгоритм выбора архитектурного решения.
Внешние обработки и отчеты (.epf / .erf)
Использование внешних обработок — это классический метод доработки систем 1С, который долгие годы оставался самым популярным решением для сохранения типовой конфигурации на поддержке. Однако у него есть как весомые преимущества, так и критические недостатки, которые необходимо учитывать.
Преимущества использования внешних файлов:
Простота обновления системы. Главный аргумент сторонников внешних файлов. Конфигурация остается полностью типовой (на поддержке), что позволяет обновлять базу данных в автоматическом режиме без необходимости привлечения программиста для объединения кода.
Быстрое внесение изменений (отладка). Изменить алгоритм внешней обработки можно «на лету». Вам не нужно монопольно выгонять пользователей из базы, применять динамическое обновление конфигурации (которое нередко приводит к невосстановимым ошибкам базы данных) или обновлять конфигурацию базы данных в принципе. Достаточно просто перезаписать файл или обновить его в справочнике дополнительных обработок.
Безопасность основной базы. Ошибки в коде внешней обработки не могут «сломать» структуру метаданных основной конфигурации.
Недостатки и «подводные камни» внешних обработок:
Проблемы с глобальным поиском и рефакторингом. Если вы проводите масштабное изменение структуры метаданных (например, переименовываете реквизит справочника или меняете тип данных), глобальный поиск конфигуратора по умолчанию не найдет ссылки на измененные объекты во внешних файлах. Это может привести к внезапным ошибкам Поле объекта не обнаружено у пользователей при запуске внешней обработки.
Трудности администрирования и прав доступа. На внешние обработки невозможно стандартным образом назначить специфические роли в конфигураторе или красиво включить их в интерфейс подсистем без использования механизмов библиотеки стандартных подсистем (БСП). Программный вызов таких обработок из встроенного языка также требует написания дополнительного обвязочного кода.
Проблема дублирования открытых форм. Пользователи часто склонны открывать одну и ту же внешнюю обработку несколько раз, что может приводить к перезаписи данных и логическим ошибкам. Чтобы предотвратить это поведение, нам необходимо программно ограничивать повторное открытие. Рассмотрим, как это сделать, задав уникальный ключ формы:
&НаКлиенте
Процедура ПриОткрытии(Отказ)
// Устанавливаем ключ уникальности, чтобы предотвратить повторное открытие этой же формы
ЭтаФорма.КлючУникальности = "УникальныйИдентификаторМоейОбработки";
КонецПроцедуры
Как настроить глобальный поиск по внешним файлам?
Многие разработчики ошибочно полагают, что глобальный поиск конфигуратора полностью бесполезен при работе с внешними обработками. Разберем по шагам, как решить эту проблему:
В поле «Пути» укажите каталог на диске, где вы храните исходные файлы ваших внешних отчетов и обработок (например, локальную рабочую копию репозитория).
Вы можете дополнительно настроить фильтры по типам файлов (указав маски *.epf или *.erf). Это позволит вам находить измененные методы и обращения к реквизитам даже во внешнем коде.
Встроенные объекты в основной конфигурации
Интеграция обработок и отчетов непосредственно в структуру метаданных конфигурации — это выбор в пользу монолитности и максимальной управляемости кодом. Этот подход часто выбирают проектные команды на нетиповых (самописных) конфигурациях или в ситуациях, когда база данных уже давно снята с поддержки.
Почему стоит встраивать объекты в конфигурацию?
Идеально для коллективной разработки. Если над проектом работают несколько специалистов (например, команда из 5 и более человек), координировать разработку на внешних файлах становится невозможно. Встроенные объекты позволяют использовать ХранилищеКонфигурации, контролировать версии, захватывать объекты для редактирования и избегать ситуаций, когда актуальная версия обработки пересылается по почте или теряется на диске.
Полная поддержка глобального поиска. Любой поиск ссылок, замена имен процедур и функций или изменение типов данных мгновенно отразится на всех встроенных обработках.
Простота интеграции. Встроенный объект легко привязать к любой подсистеме, вывести на рабочий стол пользователя, назначить права доступа через стандартные роли конфигурации и вызывать из любого общего модуля без лишних транзакций по чтению двоичных данных из СУБД.
Главный минус: Необходимость обновления конфигурации базы данных при любом изменении кода, что усложняет поддержку типовых решений и требует регулярных обновлений метаданных на рабочих серверах.
Расширения конфигурации (.cfe): современный стандарт разработки
Расширения конфигурации представляют собой гибкий инструмент, объединяющий преимущества внешних обработок и встроенных объектов. Начиная с версий платформы 1С 8.3.10-8.3.13, этот механизм превратился в мощную среду для кастомизации прикладных решений.
Преимущества разработки в расширениях:
База данных остается на стандартной поддержке поставщика.
Разработка ведется в привычном режиме дерева метаданных: вы можете добавлять новые реквизиты, создавать собственные справочники, документы и регистры.
Доступна полноценная коллективная разработка через механизмы Хранилища конфигурации расширения.
Вы можете легко перехватывать и изменять логику проведения стандартных документов с помощью аннотаций &Перед, &После и &Вместо.
Однако помните, что расширения в некоторых устаревших версиях платформы или при работе в режиме совместимости могут демонстрировать нестабильность при реструктуризации данных. Поэтому при добавлении новых справочников и документов внутри расширений необходимо тщательно тестировать процесс обновления на копиях баз данных.
Анализ производительности: внешние объекты против встроенных
Давайте проанализируем критически важный аспект, о котором часто забывают разработчики при проектировании архитектуры — это производительность работы кода. Фирма «1С» на ресурсах информационно-технологического сопровождения (ИТС) опубликовала официальные результаты замеров производительности выполнения алгоритмов в различных режимах компиляции.
Выясним причину, почему внешние обработки проигрывают встроенным по скорости работы. Дело в том, что модули объектов конфигурации и расширений компилируются однократно в рамках сеанса работы. Модули же внешних обработок вынуждены компилироваться сервером повторно при каждом вызове метода инициализации или при загрузке бинарного файла из СУБД (хранилища дополнительных обработок БСП).
Рассмотрим результаты официального нагрузочного теста «1С» при работе 100 активных пользователей:
Встроенная в конфигурацию обработка (базовый эталон): Загрузка процессора сервера — около 33%, общее время выполнения пакета задач — 322 секунды.
Обработка, реализованная в расширении (.cfe): Загрузка процессора сервера возрастает до 46% (рост на 39% относительно базы), время выполнения увеличивается до 406 секунд. Это связано с накладными расходами платформы на сопоставление метаданных расширения и основной конфигурации.
Внешняя обработка (.epf файл): Показывает самые слабые результаты. Загрузка процессора сервера подскакивает до 80% (рост нагрузки более чем в 2.4 раза!), а время выполнения увеличивается до 513 секунд.
Важный вывод: Если ваш отчет или обработка запускаются пользователями редко (например, регламентный отчет раз в месяц) или выполняют простую задачу, разница будет незаметна. Но если речь идет о высоконагруженных алгоритмах, массовой обработке проведения документов, интеграционных шинах данных или формах, с которыми ежедневно работают десятки операторов — перенос кода во внешнюю обработку гарантированно приведет к замедлению работы всей системы.
Матрица принятия решений: что и когда выбирать?
Чтобы систематизировать полученные знания, разберем по шагам алгоритм выбора оптимального формата для вашей задачи:
Вам нужно быстро внедрить простую печатную форму или специфический отчет для одного отдела.
Конфигурация находится на строгой поддержке, и изменения в код вносятся оперативно, «на лету».
Выполняется разовая задача по исправлению исторических данных в СУБД или разовый перенос остатков.
Выбирайте Расширение конфигурации (.cfe), если:
База должна оставаться на поддержке, но вам требуется глубокая кастомизация бизнес-логики (например, изменение проведения документов или добавление новых реквизитов).
Необходимо использовать Хранилище конфигурации для совместной работы нескольких программистов над новой подсистемой.
Требуется полноценная интеграция с интерфейсом и правами доступа без изменения метаданных поставщика.
Выбирайте Встроенный объект конфигурации, если:
База полностью самописная или уже снята с поддержки, и вы хотите минимизировать любые накладные расходы платформы на компиляцию и сопоставление метаданных.
Разрабатываемый функционал критичен к скорости выполнения (высоконагруженные расчеты, регламентные задания, фоновые процессы).
Требуется стопроцентная надежность при глобальном поиске и автоматическом рефакторинге кода всей системы.
Применяя эти правила на практике, вы сможете соблюдать идеальный баланс между скоростью разработки, производительностью серверного оборудования и простотой последующей поддержки вашей информационной системы на платформе «1С:Предприятие 8».