Как правильно создавать обертки в модулях «Вызов сервера» для серверных процедур?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При разработке на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с дилеммой: где разместить серверную процедуру, которая должна вызываться как с клиента, так и с сервера. Если поместить ее напрямую в модуль с флагом Вызов сервера, мы рискуем «размазать» серверный интерфейс по разным модулям. Если же оставить ее в обычном серверном модуле и сделать «обертку» в модуле вызова сервера, возникает проблема дублирования кода и документации. В этой статье мы подробно разберем, как организовать этот процесс эффективно, следуя лучшим практикам и стандартам разработки.

Анализ подходов к организации серверного кода

Рассмотрим две основные стратегии, которые обсуждаются в сообществе разработчиков 1С:

  1. Размещение процедуры только в модуле «Вызов сервера». Этот подход исключает дублирование, но нарушает логику группировки серверных методов. Серверный интерфейс становится трудноохватываемым, так как часть логики лежит в одном месте, а часть — в другом.
  2. Размещение логики в модуле «Сервер» с созданием обертки в «Вызов сервера». Это более строгий архитектурный подход. Основной модуль сервера содержит всю бизнес-логику, а модуль вызова сервера служит лишь «шлюзом» для клиента. Однако здесь остро встает вопрос актуализации документации в комментариях.

Проанализируем ситуацию: почему второй подход считается более профессиональным? Модуль с флагом Вызов сервера — это публичный интерфейс вашего сервера для тонкого клиента. Согласно принципу Separation of Concerns (разделение ответственности), бизнес-логика не должна зависеть от того, каким способом ее вызвали. Поэтому правильным считается вынесение логики в неконтекстный серверный модуль.

Проблема дублирования документации и ее решение

Многие разработчики опасаются, что при изменении сигнатуры метода в серверном модуле они забудут обновить обертку. Чтобы минимизировать риск расхождений, в Библиотеке стандартных подсистем (БСП) и стандартах 1С применяются следующие приемы:

Вместо копирования всего блока описания параметров (программного интерфейса), в модуле-обертке используется краткая ссылка. Рассмотрим, как это выглядит на практике:


// В модуле ОбщегоНазначенияСервер (Сервер)
// Выполняет расчет остатков по складу.
//
// Параметры:
//  Склад - СправочникСсылка.Склады - Склад для расчета.
//  Дата  - Дата - Момент времени.
//
// Возвращаемое значение:
//  Число - Сумма остатка.
Функция ОстатокНаСкладе(Склад, Дата) Экспорт
    // ... логика расчета ...
КонецФункции

// В модуле ОбщегоНазначенияВызовСервера (Вызов сервера)
// См. ОбщегоНазначенияСервер.ОстатокНаСкладе
Функция ОстатокНаСкладе(Склад, Дата) Экспорт
    Возврат ОбщегоНазначенияСервер.ОстатокНаСкладе(Склад, Дата);
КонецФункции

Такой подход позволяет хранить описание логики и параметров только в одном месте. Если вы используете среду разработки 1C:EDT, аннотации типа @see помогут среде автоматически связывать эти методы, обеспечивая удобную навигацию.

Модуль «Вызов сервера» как адаптер типов данных

Выясним важный момент: модуль вызова сервера не всегда является «пустой» оберткой. Одной из его ключевых функций является преобразование типов. Серверные методы часто работают с объектами, которые недоступны на клиенте или не могут быть переданы по сети (например, ТаблицаЗначений, МенеджерЗаписи).

Проанализируем пример, где модуль вызова сервера выступает в роли адаптера:


// В серверном модуле логика работает с таблицей значений
Функция ПолучитьДанныеДляОтчета() Экспорт
    ТЗ = Новый ТаблицаЗначений;
    // ... заполнение ТЗ ...
    Возврат ТЗ;
КонецФункции

// В модуле вызова сервера мы преобразуем ТЗ в массив структур для клиента
Функция ПолучитьДанныеДляОтчета() Экспорт
    ДанныеТЗ = МойСерверныйМодуль.ПолучитьДанныеДляОтчета();
    Возврат ОбщегоНазначения.ТаблицаЗначенийВМассив(ДанныеТЗ);
КонецФункции

В этом случае это уже не «лишний шаблонный код», а необходимая логика подготовки данных для передачи на тонкий клиент. При таком подходе клиент всегда получает универсальные коллекции (массивы, структуры), а сервер внутри себя оперирует производительными серверными типами.

Рекомендации по организации структуры модулей

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

Важный нюанс: Стандарты разработки 1С рекомендуют не ставить флаг Внешнее соединение у модулей вызова сервера. Это подтверждает концепцию того, что данные модули предназначены исключительно для взаимодействия Клиент -> Сервер.

Заключение: лучший выбор для чистого кода

Подводя итог, разберем по шагам создание идеальной обертки:

  1. Реализуйте основную логику в модуле ИмяМодуляСервер. Тщательно задокументируйте все параметры и возвращаемые значения.
  2. Создайте в модуле ИмяМодуляВызовСервера одноименную функцию.
  3. В комментарии к обертке напишите // См. ИмяМодуляСервер.ИмяПроцедуры.
  4. Если серверный метод возвращает ТаблицуЗначений, в обертке обязательно преобразуйте ее в Массив структур.
  5. Если метод требует проверки прав доступа или установки привилегированного режима, делайте это именно в точке входа — в модуле вызова сервера.

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

← На главную