Основные понятия и механизмы оптимизации клиент-серверного взаимодействия в 1C

Начиная с платформы 8.2 (далее управляемое приложение), разработчикам стала доступна возможность самим определять, где будет выполняться код, на севере или на клиенте. Такая необходимость возникла в связи с появлением "тонкого клиента" и "веб-клиента", которые могут работать через интернет, что несомненно накладывает определенные ограничения на передачу данных.

В предыдущих версиях платформы 8.0 и 8.1 (далее обычное приложение) не было нужды задумываться над указанием директив выполнения функций, так как на клиенте был доступен тот же функционал, что и на сервере, т.е. на форме можно было напрямую обратиться к объекту справочника или документа или выполнить запрос к базе данных, но теперь для этого необходимо явно указать директиву компиляции.

Прежде чем переходить к основной части, сделаем предположение, что Вы уже знакомы с клиент-серверной архитектурой в 1С, если же нет, то советую предварительно с ней ознакомиться.

Директивы компиляции

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

Так вот, директивы компиляции - это специальные ключевые слова, позволяющие указать платформе, в каком контексте необходимо выполнить процедуру или функцию.

Указывать директивы для процедур и функций можно не только в модулях форм, но и в модулях команд, а также общих модулях, однако использовать их рекомендуется только в модулях управляемых форм и в модулях команд.

Существует пять различных директив:

&НаКлиенте
&НаСервере
&НаСервереБезКонтекста
&НаКлиентеНаСервереБезКонтекста
&НаКлиентеНаСервере

Рассмотрим их подробнее:
Директива &НаКлиенте указывает на то, что код функций/процедур будет выполняться в контексте клиентского приложения, где будут доступны только элементы, параметры и реквизиты формы.
Доступны вызовы любых процедур модуля формы.

При указании директивы &НаСервере, для процедур/функций будут доступны не только данные формы, но и возможность обращаться к данным базы. Выполнение кода будет происходить на сервере.
Обращение к процедурам на клиенте уже не доступно. Т.е., находясь на сервере, нельзя инициировать вызов клиентских процедур и функций.

Начиная с платформы 8.3.10 стала доступна возможность получать данные с клиента на сервере, используя систему взаимодействия.

Если указана директива &НаСервереБезКонтекста, это означает, что код будет выполняться на сервере, но доступа к контексту формы (реквизиты, параметры, элементы) уже не будет.
Доступны вызовы только внеконтекстных процедур и функций.

Директива &НаКлиентеНаСервереБезКонтекста необходима, если требуется выполнение процедуры/функции и на сервере и на клиенте. Данная директива используется редко, но является полезной и позволяет вместо двух процедур, для выполнения в разных контекстах, указать всего одну.

Последняя директива &НаКлиентеНаСервере по сути аналогична &НаКлиентеНаСервереБезКонтекста, но доступна она только в модуле команд.

Если по ошибке не указать директиву, то платформа сама ее поставит. По умолчанию это директива &НаСервере.

Помимо директив, существуют еще и инструкции препроцессора, которые обозначаются символом #. Они действуют на исходный текст модулей и выполняются перед компиляцией кода. В результате применения директив и инструкций, в скомпилированном модуле остается только то, что должно присутствовать в том или ином контексте.
 

Контекстные и внеконтекстные вызовы

Разобравшись с тем, что такое директивы, разберем понятие контекста.

"Контекст" - это так называемое окружение, в котором доступны определенные свойства, методы, набор объектов встроенного языка, а также процедуры и функции.

Контекст может быть глобальным и локальным (контекст конкретного модуля). Глобальный контекст доступен в любой точке конфигурации, локальный же в пределах одного модуля. В свою очередь, в пределах одного модуля, контекст также можно разделить на клиентский и серверный, т.е. процедуры и функции одного модуля могут быть выполнены в разных контекстах.

Контекстный вызов формы является довольно затратным процессом, понять это можно при рассмотрении процесса взаимодействия клиентской и серверной части формы.

Если для процедуры/функции указать директиву &НаСервере, то при ее вызове будет происходить передача всей формы на сервер, т.е. все реквизиты, параметры и элементы формы будут специальным образом упакованы и переданы на сервер. На сервере полученный "контейнер" распаковывается и дальше происходит инициализация модуля формы.

После выполнения кода на сервере выполняется обратный процесс, происходит упаковка и передача на клиент контекста формы. На клиенте происходит распаковка и синхронизация данных формы. Контекст формы на сервере при этом уничтожается.

Для уменьшения объема передаваемых данных на сервер как раз и используется внеконтекстный вызов, процедуры/функции при этом должны быть помечены директивой &НаСервереБезКонтекста.

Для более детального изучения вопроса о клиент-серверных вызовах, рекомендую к прочтению статью, где все отлично описано и показано.

Выбор контекста для общих модулей

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

• Модуль управляемого приложения
• Модуль обычного приложения
• Модуль сеанса
• Модуль внешнего соединения
• Общие модули
• Модули команд
• Модули менеджера
• Модуль объекта

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

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

Если установить флаг Клиент (Управляемое приложение), то все процедуры и функции будут выполняться в контекстах "тонкого клиента", веб-клиента и "толстого клиента" в режиме управляемого приложения, при этом явно указывать директиву компиляции &НаКлиенте не требуется.

Установка флага Клиент (Обычное приложение) означает использование кода в "толстом клиенте" в режиме обычного приложения.

Установка флага Сервер позволяет выполнять код в контексте сервера и указание директивы &НаС ервере также не требуется.

Не рекомендуется создавать клент-серверные общие модули из соображений повышения модульности прикладного решения и снижения риска возникновения ошибок в таких модулях.

Свойство Внешнее соединение используется для выполнения процедур и функций при подключении внешним источником, например COM.

Следующим важным свойством является Вызов сервера. Оно доступно только в модулях, с установленным признаком Сервер и позволяет на клиенте вызывать экспортные процедуры и функции этого серверного модуля.

Свойство Вызов сервера следует устанавливать только, если действительно есть необходимость вызова из клиентского кода. Установка данного свойства не безопасна, так как клиентское приложение в режиме "тонкого клиента" и веб-клиента обращается к серверу по средствам открытого протокола http и злоумышленник может получить доступ к пользовательским данным путем обращения к серверу с помощью сторонних программ.

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

Следует также уделять особое внимание серверным процедурам и функциям, которые используют привилегированный режим.

Оптимизация клиент-серверного взаимодействия в управляемых формах

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

• Стараться уменьшать число серверных вызовов. По-хорошему, открытие формы, да и в целом, каждое действие пользователя должно происходить за один серверный вызов, однако обязательным данное требование не является.
• Необходимо пытаться уменьшать объем передаваемых данных между клиентом и сервером , например используя бесконтекстные вызовы.
• По возможности реализовывать алгоритмы с минимальным включением кода на клиенте, но и не забывать при этом уменьшать количество обращений на сервер.

В рамках статьи приведем несколько примеров оптимизации.

1) Объединение нескольких вызовов сервера в один.
Имеется задача, в которой нам требуется вывести артикул, единицу измерения и цену в строке при выборе товара.
Сразу определимся, что на клиенте данные по ссылке мы получить не сможем и нам придется "сходить" за ними на сервер.

Итак, рассмотрим несколько вариантов решения: 
Первый: Создадим общий модуль "РаботаСТЧ" и установим у него галочки Сервер и Вызов сервера. В него добавим экспортную функцию, возвращающую данные по передаваемой в нее ссылке.

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

В модуле формы, в обработчике события ПриИзменении() для поля Номенклатура добавим код, в котором и будем вызывать экспортную процедуру из общего модуля.

&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
    ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
    Номенклатура = ДанныеТекСтроки.Номенклатура;
    
    ДанныеТекСтроки.Артикул = РаботаСТЧ.ПолучитьДанные(Номенклатура,"Артикул");
    ДанныеТекСтроки.ЕдиницаИзмерения = РаботаСТЧ.ПолучитьДанные(Номенклатура,"ЕдиницаИзмерения");
    ДанныеТекСтроки.Цена = РаботаСТЧ.ПолучитьДанные(Номенклатура,"Цена");
КонецПроцедуры

Второй: В процедуре ПриИзменении() сделаем теперь вызов функции, которая вернет структуру со всеми нужными реквизитами.

&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
    ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
    РеквизитыТовара = РаботаСТЧ.ПолучитьДанные(ДанныеТекСтроки.Номенклатура);
    
    ДанныеТекСтроки.Артикул = РеквизитыТовара.Артикул;
    ДанныеТекСтроки.ЕдиницаИзмерения = РеквизитыТовара.ЕдиницаИзмерения;
    ДанныеТекСтроки.Цена = РеквизитыТовара.Цена;
КонецПроцедуры

В экспортную функцию так же внесем поправки.

Функция ПолучитьДанные(Ссылка) Экспорт
      ДанныеРеквизитов = Новый Структура;
      ДанныеРеквизитов.Вставить("Артикул",Ссылка.Артикул);
      ДанныеРеквизитов.Вставить("ЕдиницаИзмерения",Ссылка.ЕдиницаИзмерения);
      ДанныеРеквизитов.Вставить("Цена",Ссылка.Цена);
      
      Возврат ДанныеРеквизитов;
КонецФункции

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

2) Использование внеконтекстных процедур или функций.
Предположим, что у нас есть периодический регистр с ценами. При выборе номенклатуры в табличной части документа необходимо, чтобы цена автоматически проставлялась из этого регистра, на дату документа.

Рассмотрим примеры: 
Первый: Так как нам необходим доступ к базе, то получать данные мы будем с сервера, а значит можно сразу, все что нужно, сделать на сервере. В модуле формы, в обработчике события ПриИзменении() обратимся к серверной процедуре в этом же модуле.

&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
    ЗаполнитьЦенуНаСервере()    
КонецПроцедуры

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

Обратите внимание на то, что на сервере имеется доступ к элементам формы Элементы.Товары.ТекущаяСтрока. Благодаря использованию директивы &НаСервере в процедуру передается весь контекст формы и мы можем обратиться к элементам формы.

Второй: В данном варианте мы изменим процедуру ПриИзменении(). Теперь будем подставлять цену не на сервере, а на клиенте. Функцию получения цены выполним, используя директиву &НаСервереБезКонтекста. Таким образом, на сервер будут переданы всего два значения, а не весь контекст формы.

&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
    ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
    ДанныеТекСтроки.Цена = ЗаполнитьЦенуНаСервере(ДанныеТекСтроки.Номенклатура, Объект.Дата)    
КонецПроцедуры

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

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

Заключение

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

Для более подробного изучения вопросов оптимизации рекомендую к прочтению книгу "Разработка интерфейса прикладных решений на платформе "1С:Предприятие 8".

Спасибо за внимание, надеюсь данный материал оказался для Вас полезным!