Почему серверные методы глобальных общих модулей недоступны на клиенте и как работает вызов сервера

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

Особенности глобальных и неглобальных общих модулей

Разберем базовые различия в том, как платформа компилирует и предоставляет доступ к методам общих модулей разного типа:

1. Неглобальные общие модули: не включаются напрямую в глобальное пространство имен. Для обращения к их процедурам и функциям разработчик явно указывает имя модуля через точку, например: ОбщегоНазначенияКлиентСервер.СообщитьПользователю(...).
2. Глобальные общие модули: их методы компилируются непосредственно в глобальный контекст приложения. Обращение к ним происходит напрямую по имени метода без указания имени модуля, например: МояГлобальнаяФункция(...).

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

Почему флаг «Вызов сервера» не работает для глобальных модулей

Проанализируем механизм клиент-серверного взаимодействия (RPC — Remote Procedure Call) в тонком и веб-клиенте управляемого приложения:

1. Создание клиентских прокси-объектов: когда для неглобального серверного общего модуля включено свойство Вызов сервера, платформа 1С автоматически генерирует на стороне тонкого клиента специальный прокси-объект с именем этого модуля. При вызове метода через этот прокси происходит сериализация параметров, передача HTTP/TCP-запроса на сервер, выполнение серверного кода и возврат результата обратно на клиент.
2. Отсутствие прокси для глобального контекста: для глобального модуля прокси-объект по имени модуля создать невозможно, так как концепция глобального модуля изначально исключает обращение через имя объекта метаданных.
3. Защита от неявных сетевых вызовов: если бы серверные методы глобальных модулей прозрачно подмешивались в клиентский глобальный контекст, разработчик при написании кода не видел бы разницы между локальной быстрой операцией и тяжелым сетевым синхронным вызовом. Это приводило бы к критическим просадкам производительности интерфейса.
4. Исключение коллизий имен: объединение серверных и клиентских пространств имен в единый глобальный контекст неизбежно приводило бы к конфликтам имен функций между клиентом и сервером.

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

Ограничения глобальных модулей в платформе 1С

Рассмотрим другие важные ограничения, накладываемые платформой на глобальные общие модули:

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

Стандарты разработки и шаблоны разделения модулей

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

1. <Имя>Клиент — модуль со свойством Клиент (управляемое приложение). Содержит только клиентскую логику взаимодействия с пользователем.
2. <Имя>Сервер — модуль со свойством Сервер. Содержит основную бизнес-логику, запросы к базе данных и обработку объектов.
3. <Имя>КлиентСервер — модуль со свойствами Клиент (управляемое приложение) и Сервер. Содержит алгоритмы без обращения к базе данных (проверки, преобразования строк, расчеты).
4. <Имя>ВызовСервера — фасадный модуль со свойствами Сервер и Вызов сервера. Выступает компактной точкой входа для вызовов с клиента.

Посмотрим на пример правильной организации вызова серверного метода с клиента через фасадный модуль:

В модуле РаботаСДокументамиВызовСервера (свойства: Сервер, Вызов сервера):

Функция ПолучитьСтатусДокумента(СсылкаНаДокумент) Экспорт
    Возврат РаботаСДокументамиСервер.ПолучитьСтатусДокумента(СсылкаНаДокумент);
КонецФункции

В клиентском коде формы или клиентского модуля вызов выполняется явно и прозрачно:

&НаКлиенте
Процедура ПроверитьСтатус(Команда)
    ТекущийСтатус = РаботаСДокументамиВызовСервера.ПолучитьСтатусДокумента(Объект.Ссылка);
    ПоказатьОповещениеПользователя("Статус документа", , ТекущийСтатус);
КонецПроцедуры

Вызовы в контексте самой формы

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

1. &НаСервереБезКонтекста — вызывается с клиента без передачи данных формы на сервер. Минимизирует сетевой трафик и ускоряет работу.
2. &НаСервере — передает на сервер весь контекст формы (реквизиты и состояние элементов). Используется только тогда, когда серверу необходим доступ ко всем данным текущей формы.

&НаКлиенте
Процедура ВыполнитьРасчет(Команда)
    Результат = РассчитатьНаСервере(Объект.Сумма, Объект.Процент);
КонецПроцедуры

&НаСервереБезКонтекста
Функция РассчитатьНаСервере(Сумма, Процент)
    Возврат Сумма * (Процент / 100);
КонецФункции