В чем разница между свойствами общих модулей «Клиент-Сервер» и «Вызов сервера»?

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

Понимание настройки «Клиент» и «Сервер»

Когда мы устанавливаем галочки Клиент и Сервер для общего модуля, мы сообщаем платформе, что этот код может быть скомпилирован для работы в обоих контекстах. Важно понимать следующее:

• Отсутствие автоматического вызова: Если вы вызываете процедуру из такого модуля, находясь на клиенте (например, в форме), код выполняется на клиенте. Если же вы обращаетесь к той же процедуре из серверного контекста, код выполняется на сервере.
• Отсутствие «магического» переноса: Платформа не делает автоматический вызов сервера при обращении к функциям такого модуля с клиента. Если код модуля требует серверных ресурсов (например, запроса к базе данных), а вы вызвали его с клиента, возникнет ошибка исполнения.
• Назначение: Этот тип модулей идеально подходит для вспомогательной логики: математических вычислений, обработки коллекций (массивов, структур, соответствий), форматирования текста или проверки данных, которые не требуют обращения к объектам базы данных.

Разбираем работу модуля с «Вызовом сервера»

Модуль, для которого установлены свойства Сервер и Вызов сервера, работает принципиально иначе. Это исключительно серверный код, который становится «доступным» для клиентского вызова. Рассмотрим особенности:

1. Принудительный вызов сервера: При обращении из клиентского кода к процедуре такого модуля, платформа инициирует вызов сервера. Происходит передача параметров, исполнение кода в контексте сервера и возврат результата.
2. Ограничения производительности: Поскольку каждый такой вызов — это сетевая операция, необходимо учитывать нагрузку на канал связи. Не стоит злоупотреблять «Вызовом сервера» в циклах или при частых вызовах.
3. Безопасность: Весь код, находящийся в модуле с «Вызовом сервера», исполняется на сервере. Это означает, что он имеет доступ к данным информационной базы, но при этом требует строгой проверки прав пользователя, так как доступ к нему открыт из интерфейса.

Сравнение и выбор стратегии разработки

Чтобы лучше понять, какой инструмент выбрать, давайте проанализируем сценарии использования:

Сценарий 1: Работа с данными
Если вам нужно, чтобы код работал как на клиенте, так и на сервере без создания лишних сетевых запросов (например, функция ПреобразоватьДатуВСтроку), используйте модуль с флагами Клиент и Сервер.

Сценарий 2: Получение данных из БД
Если вам нужно получить данные из справочника или документа при нажатии на кнопку в форме, ваш путь — модуль с флагами Сервер и Вызов сервера. Попытка сделать запрос к базе данных в клиентском модуле приведет к ошибке.

Пример архитектурного подхода:

// Пример логики в модуле с флагом «Вызов сервера»
Функция ПолучитьДанныеКонтрагента(СсылкаНаКонтрагента) Экспорт
    // Код выполняется строго на сервере
    // Доступны все объекты БД
    Возврат СсылкаНаКонтрагента.Наименование;
КонецФункции

Важные нюансы компиляции

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

Подытожим наши выводы:

• Клиент + Сервер: Для быстрого кода без обращения к БД, выполняемого в месте вызова.
• Сервер + Вызов сервера: Для функций, требующих доступа к данным, которые нужно вызывать из интерфейса.
• Только Сервер: Для обеспечения изоляции логики, когда вы хотите запретить прямой вызов функций из интерфейса пользователя.

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