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