← На главную

При разработке на платформе 1С:Предприятие часто возникает вопрос о том, где правильнее размещать новые объекты метаданных: непосредственно в основной конфигурации или же выносить их в расширения. Рассмотрим подробно архитектурные аспекты этого решения, проанализируем риски и определим лучшие практики.

Техническая возможность создания объектов в расширениях

Начнем с того, что технически создание новых объектов (справочников, документов, регистров сведений и т.д.) возможно в любом расширении, вне зависимости от его типа назначения (Адаптация, Дополнение или Исправление). Назначение расширения в первую очередь определяет приоритет применения, если их установлено несколько. Система позволяет разработчику добавлять объекты внутри любого из этих типов, так как ограничение на добавление метаданных связано скорее с архитектурной политикой компании, а не с жестким запретом платформы.

Основные архитектурные риски

Хотя возможность создания объектов есть, опытные разработчики рекомендуют подходить к этому с осторожностью. Разберем основные причины, почему стоит избегать бездумного создания метаданных в расширениях:

1. Целостность данных при операциях обслуживания: При добавлении реквизитов к типовым объектам через расширения, платформа создает дополнительные таблицы в СУБД. Существует риск, что при выполнении операции Тестирование и исправление (ТИИ) или при обновлении структуры базы данных, связи между объектами могут быть нарушены, так как механизмы платформы не всегда корректно интерпретируют расширенные метаданные.
2. Потеря данных при переустановке: Если расширение будет удалено и добавлено заново (например, при критическом сбое или смене порядка применения), данные, хранящиеся в созданных объектах метаданных, могут оказаться недоступными или быть удалены, если они не были корректно перенесены.
3. Усложнение отладки: Когда логика «размазана» между основной конфигурацией и несколькими расширениями, процесс отладки становится крайне затруднительным. Использование конструктора запросов также становится менее удобным, так как он не всегда видит «расширенные» объекты так же прозрачно, как объекты основной конфигурации.

Рекомендуемые подходы к разработке

Чтобы избежать описанных проблем, рекомендуем придерживаться следующих правил проектирования:

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

2. Изолируйте новые объекты. Если задача требует создания абсолютно нового справочника или регистра сведений, делайте это в отдельном расширении с назначением Дополнение. Это позволит изолировать вашу разработку от основного кода системы.

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

Как обеспечить обновляемость конфигурации?

Распространено заблуждение, что создание объектов в расширении — единственный способ сохранить возможность автоматического обновления типовой конфигурации. На самом деле, это не совсем так. Основная конфигурация вполне может быть обновлена даже с доработками. Однако использование расширений действительно минимизирует количество конфликтов при сравнении и объединении с новым релизом от поставщика.

Если вы все же решаете создавать объекты в расширении, следуйте этим шагам:

1. Документирование: Всегда фиксируйте, какие именно объекты были созданы в расширениях. Если в будущем потребуется передать проект другому разработчику, это сэкономит сотни часов на поиск причин ошибок в структуре данных.
2. Минимализм: Старайтесь не создавать «монструозные» расширения. Лучше разбить функционал на несколько небольших расширений, которые отвечают за конкретные задачи.
3. Безопасный режим: Старайтесь использовать возможности платформы по работе с расширениями в безопасном режиме, насколько это позволяет функционал вашего решения.

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