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