Начиная с платформы 8.2 (далее управляемое приложение), разработчикам стала доступна возможность самим определять, где будет выполняться код, на севере или на клиенте. Такая необходимость возникла в связи с появлением "тонкого клиента" и "веб-клиента", которые могут работать через интернет, что несомненно накладывает определенные ограничения на передачу данных.
В предыдущих версиях платформы 8.0 и 8.1 (далее обычное приложение) не было нужды задумываться над указанием директив выполнения функций, так как на клиенте был доступен тот же функционал, что и на сервере, т.е. на форме можно было напрямую обратиться к объекту справочника или документа или выполнить запрос к базе данных, но теперь для этого необходимо явно указать директиву компиляции.
Прежде чем переходить к основной части, сделаем предположение, что Вы уже знакомы с клиент-серверной архитектурой в 1С, если же нет, то советую предварительно с ней ознакомиться.
Директивы компиляции
Директивы компиляции, что же это такое? Давайте сначала обозначим, что форма — это объект, который создается в процессе работы прикладного решения и состоит из двух частей, которые выполняются в двух контекстах, на клиенте и на сервере. Взаимодействие между частями осуществляется с помощью серверного вызова.
Так вот, директивы компиляции — это специальные ключевые слова, позволяющие указать платформе, в каком контексте необходимо выполнить процедуру или функцию.
Указывать директивы для процедур и функций можно не только в модулях форм, но и в модулях команд, а также общих модулях, однако использовать их рекомендуется только в модулях управляемых форм и в модулях команд.
Существует пять различных директив:
&НаКлиенте
&НаСервере
&НаСервереБезКонтекста
&НаКлиентеНаСервереБезКонтекста
&НаКлиентеНаСервере
Рассмотрим их подробнее:
Директива &НаКлиенте указывает на то, что код функций/процедур будет выполняться в контексте клиентского приложения, где будут доступны только элементы, параметры и реквизиты формы.
Доступны вызовы любых процедур модуля формы.
При указании директивы &НаСервере, для процедур/функций будут доступны не только данные формы, но и возможность обращаться к данным базы. Выполнение кода будет происходить на сервере.
Обращение к процедурам на клиенте уже не доступно. Т.е., находясь на сервере, нельзя инициировать вызов клиентских процедур и функций.
Начиная с платформы 8.3.10 стала доступна возможность получать данные с клиента на сервере, используя систему взаимодействия.
Если указана директива &НаСервереБезКонтекста, это означает, что код будет выполняться на сервере, но доступа к контексту формы (реквизиты, параметры, элементы) уже не будет.
Доступны вызовы только внеконтекстных процедур и функций.
Директива &НаКлиентеНаСервереБезКонтекста необходима, если требуется выполнение процедуры/функции и на сервере и на клиенте. Данная директива используется редко, но является полезной и позволяет вместо двух процедур, для выполнения в разных контекстах, указать всего одну.
Последняя директива &НаКлиентеНаСервере по сути аналогична &НаКлиентеНаСервереБезКонтекста, но доступна она только в модуле команд.
Если по ошибке не указать директиву, то платформа сама ее поставит. По умолчанию это директива &НаСервере.
Помимо директив, существуют еще и инструкции препроцессора, которые обозначаются символом #. Они действуют на исходный текст модулей и выполняются перед компиляцией кода. В результате применения директив и инструкций, в скомпилированном модуле остается только то, что должно присутствовать в том или ином контексте.
Контекстные и внеконтекстные вызовы
Разобравшись с тем, что такое директивы, разберем понятие контекста.
"Контекст" — это так называемое окружение, в котором доступны определенные свойства, методы, набор объектов встроенного языка, а также процедуры и функции.
Контекст может быть глобальным и локальным (контекст конкретного модуля). Глобальный контекст доступен в любой точке конфигурации, локальный же в пределах одного модуля. В свою очередь, в пределах одного модуля, контекст также можно разделить на клиентский и серверный, т.е. процедуры и функции одного модуля могут быть выполнены в разных контекстах.
Контекстный вызов формы является довольно затратным процессом, понять это можно при рассмотрении процесса взаимодействия клиентской и серверной части формы.
Если для процедуры/функции указать директиву &НаСервере, то при ее вызове будет происходить передача всей формы на сервер, т.е. все реквизиты, параметры и элементы формы будут специальным образом упакованы и переданы на сервер. На сервере полученный "контейнер" распаковывается и дальше происходит инициализация модуля формы.
После выполнения кода на сервере выполняется обратный процесс, происходит упаковка и передача на клиент контекста формы. На клиенте происходит распаковка и синхронизация данных формы. Контекст формы на сервере при этом уничтожается.
Для уменьшения объема передаваемых данных на сервер как раз и используется внеконтекстный вызов, процедуры/функции при этом должны быть помечены директивой &НаСервереБезКонтекста.
Для более детального изучения вопроса о клиент-серверных вызовах, рекомендую к прочтению статью, где все отлично описано и показано.
Выбор контекста для общих модулей
Выше мы рассмотрели использование директив компиляции в модулях форм, но помимо модулей форм существуют и другие виды модулей:
- Модуль управляемого приложения
- Модуль обычного приложения
- Модуль сеанса
- Модуль внешнего соединения
- Общие модули
- Модули команд
- Модули менеджера
- Модуль объекта
В рамках данной статьи не будем разбирать, какие функции возложены на каждый из модулей. Нас интересует только общий модуль, так как именно для него имеется возможность указать, в каком контексте будет скомпилирован его экземпляр.
Общие модули существуют отдельно, как объекты конфигурации и предназначены для процедур и функций, объединенных по сходным функциональным назначениям.
Для них определен следующий набор свойств: Клиент (Управляемое приложение), Клиент (Обычное приложение) Сервер, Внешнее соединение, Вызов сервера, Привилегированный, Глобальный.
Если установить флаг Клиент (Управляемое приложение), то все процедуры и функции будут выполняться в контекстах "тонкого клиента", веб-клиента и "толстого клиента" в режиме управляемого приложения, при этом явно указывать директиву компиляции &НаКлиенте не требуется.
Установка флага Клиент (Обычное приложение) означает использование кода в "толстом клиенте" в режиме обычного приложения.
Установка флага Сервер позволяет выполнять код в контексте сервера и указание директивы &НаСервере также не требуется.
Не рекомендуется создавать клент-серверные общие модули из соображений повышения модульности прикладного решения и снижения риска возникновения ошибок в таких модулях.
Свойство Внешнее соединение используется для выполнения процедур и функций при подключении внешним источником, например COM.
Следующим важным свойством является Вызов сервера. Оно доступно только в модулях, с установленным признаком Сервер и позволяет на клиенте вызывать экспортные процедуры и функции этого серверного модуля.
Свойство Вызов сервера следует устанавливать только, если действительно есть необходимость вызова из клиентского кода. Установка данного свойства не безопасна, так как клиентское приложение в режиме "тонкого клиента" и веб-клиента обращается к серверу по средствам открытого протокола http и злоумышленник может получить доступ к пользовательским данным путем обращения к серверу с помощью сторонних программ.
Выполнение в Привилегированном режиме (при установке свойства Привилегированный) означает, что разрешены любые операции и проверка доступа на уровне записей, а также то, что контроль прав производится не будут.
Следует также уделять особое внимание серверным процедурам и функциям, которые используют привилегированный режим.
Оптимизация клиент-серверного взаимодействия в управляемых формах
Разобравшись с терминами и определениями перейдем теперь к вопросам оптимизации.
Почему главный упор сделан именно на модули форм? Потому что именно они могут существовать в четырех экземплярах и в процессе работы, управление между экземплярами может передаваться. Стоит сразу оговориться, что несколько экземпляров могут иметь модули команд и общие модули, однако они не могут иметь контекстных экземпляров, как формы.
Ранее мы разбирали, что такое контекстный вызов формы и каким образом он влияет на производительность системы. Учитывая тот факт, что интерфейс 1С в режиме управляемого приложения ориентирован на возможность работы через интернет и по низкоскоростным каналам, можно определить некоторые рекомендации по оптимизации:
- Стараться уменьшать число серверных вызовов. По-хорошему, открытие формы, да и в целом, каждое действие пользователя должно происходить за один серверный вызов, однако обязательным данное требование не является.
- Необходимо пытаться уменьшать объем передаваемых данных между клиентом и сервером , например используя бесконтекстные вызовы.
- По возможности реализовывать алгоритмы с минимальным включением кода на клиенте, но и не забывать при этом уменьшать количество обращений на сервер.
В рамках статьи приведем несколько примеров оптимизации.
1) Объединение нескольких вызовов сервера в один.
Имеется задача, в которой нам требуется вывести артикул, единицу измерения и цену в строке при выборе товара.
Сразу определимся, что на клиенте данные по ссылке мы получить не сможем и нам придется "сходить" за ними на сервер.
Итак, рассмотрим несколько вариантов решения:
Первый: Создадим общий модуль "РаботаСТЧ" и установим у него галочки Сервер и Вызов сервера. В него добавим экспортную функцию, возвращающую данные по передаваемой в нее ссылке.
Функция ПолучитьДанные(Ссылка, ИмяРеквизита) Экспорт
Возврат Ссылка[ИмяРеквизита];
КонецФункции
В модуле формы, в обработчике события ПриИзменении() для поля Номенклатура добавим код, в котором и будем вызывать экспортную процедуру из общего модуля.
&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
Номенклатура = ДанныеТекСтроки.Номенклатура;
ДанныеТекСтроки.Артикул = РаботаСТЧ.ПолучитьДанные(Номенклатура,"Артикул");
ДанныеТекСтроки.ЕдиницаИзмерения = РаботаСТЧ.ПолучитьДанные(Номенклатура,"ЕдиницаИзмерения");
ДанныеТекСтроки.Цена = РаботаСТЧ.ПолучитьДанные(Номенклатура,"Цена");
КонецПроцедуры
Второй: В процедуре ПриИзменении() сделаем теперь вызов функции, которая вернет структуру со всеми нужными реквизитами.
&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
РеквизитыТовара = РаботаСТЧ.ПолучитьДанные(ДанныеТекСтроки.Номенклатура);
ДанныеТекСтроки.Артикул = РеквизитыТовара.Артикул;
ДанныеТекСтроки.ЕдиницаИзмерения = РеквизитыТовара.ЕдиницаИзмерения;
ДанныеТекСтроки.Цена = РеквизитыТовара.Цена;
КонецПроцедуры
В экспортную функцию так же внесем поправки.
&НаСервереБезКонтекста
Функция ПолучитьДанные(Ссылка) Экспорт
ДанныеРеквизитов = Новый Структура;
ДанныеРеквизитов.Вставить("Артикул",Ссылка.Артикул);
ДанныеРеквизитов.Вставить("ЕдиницаИзмерения",Ссылка.ЕдиницаИзмерения);
ДанныеРеквизитов.Вставить("Цена",Ссылка.Цена);
Возврат ДанныеРеквизитов;
КонецФункции
При анализе работы обоих вариантов видно, что более производительным является второй, так как вызов сервера происходит всего один раз, вместо трех.
Стоит так же отметить, что в экспортной функции мы получали реквизиты по ссылке. Данная возможность является удобной, но не всегда эффективной, так как происходит загрузка всего объекта в память и при большом количестве реквизитов это может сказаться на производительности. Поэтому, рекомендуется вместо обращения по ссылке использовать запросы.
2) Использование внеконтекстных процедур или функций.
Предположим, что у нас есть периодический регистр с ценами. При выборе номенклатуры в табличной части документа необходимо, чтобы цена автоматически проставлялась из этого регистра, на дату документа.
Рассмотрим примеры:
Первый: Так как нам необходим доступ к базе, то получать данные мы будем с сервера, а значит можно сразу, все что нужно, сделать на сервере. В модуле формы, в обработчике события ПриИзменении() обратимся к серверной процедуре в этом же модуле.
&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
ЗаполнитьЦенуНаСервере()
КонецПроцедуры
&НаСервере
Процедура ЗаполнитьЦенуНаСервере()
ТекущаяСтрока = Элементы.Товары.ТекущаяСтрока;
ДанныеТекСтроки = Объект.Товары.НайтиПоИдентификатору(ТекущаяСтрока);
Отбор = Новый Структура;
Отбор.Вставить("Номенклатура", ДанныеТекСтроки.Номенклатура);
ТекЦена = РегистрыСведений.ЦеныНоменклатуры.ПолучитьПоследнее(Объект.Дата, Отбор);
ДанныеТекСтроки.Цена = ТекЦена.Цена;
КонецПроцедуры
Обратите внимание на то, что на сервере имеется доступ к элементам формы Элементы.Товары.ТекущаяСтрока. Благодаря использованию директивы &НаСервере в процедуру передается весь контекст формы и мы можем обратиться к элементам формы.
Второй: В данном варианте мы изменим процедуру ПриИзменении(). Теперь будем подставлять цену не на сервере, а на клиенте. Функцию получения цены выполним, используя директиву &НаСервереБезКонтекста. Таким образом, на сервер будут переданы всего два значения, а не весь контекст формы.
&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
ДанныеТекСтроки = Элементы.Товары.ТекущиеДанные;
ДанныеТекСтроки.Цена = ЗаполнитьЦенуНаСервере(ДанныеТекСтроки.Номенклатура, Объект.Дата)
КонецПроцедуры
&НаСервереБезКонтекста
Функция ЗаполнитьЦенуНаСервере(Номенклатура, ДатаДокумента)
Отбор = Новый Структура;
Отбор.Вставить("Номенклатура", Номенклатура);
ТекЦена = РегистрыСведений.ЦеныНоменклатуры.ПолучитьПоследнее(ДатаДокумента, Отбор);
Возврат ТекЦена.Цена;
КонецФункции
Во втором варианте видно, что уменьшился объем передаваемых данных и сократилось время выполнения процедур.
Вместо передачи двух параметров в функцию, можно было упаковать их в структуру и передать в функцию, однако такая оптимизация может оказаться излишней и в итоге мы можем получить увеличение объема передаваемых данных.
Заключение
Не стоит бездумно гнаться за оптимизацией и слепо следовать рекомендациям, ведь в такой погоне программный код может стать нечитаемым, что существенно усложнит поддержку данного кода. Необходимо стремится к поиску золотой середины между оптимизацией и хорошо читаемым структурированным кодом. Помимо всего прочего, оптимизация модулей форм не является наиглавнейшей задачей для улучшения производительности системы, "узкие участки" могут скрываться и в других местах, к примеру, это могут быть неоптимально написанные запросы.
Для более подробного изучения вопросов оптимизации рекомендую к прочтению книгу "Разработка интерфейса прикладных решений на платформе "1С:Предприятие 8".
Спасибо за внимание, надеюсь данный материал оказался для Вас полезным!
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Ссылка на архитектуру «битая»
(1) спасибо. Чуть позже исправлю.
Спасибо за статью. Стоит ли ожидать следующей части, где будет раскрыта суть вопроса передачи разных типов данных между клиентом и сервером? Мне например интересно как правильно осуществлять безконтекстный серверный вызов процедуры из клиентского общего модуля имея ссылку на УФ, в которой находится ТЧ типа ДанныеФормыСтруктура. Кроме варианта перебора в цикле, создания структур и копирования всего в Массив я ничего не нашел. Несмотря на то, что ДанныеФормыСтруктура существует и на сервере — невозможно в качестве параметра передать ссылку на неё, т.к. 1С при этом начинает ругаться, что данные не предназначены для изменения.
(3) Спасибо за отзыв. Продолжения пока не планировала, но подумаю)
(3) По поводу
, просто передать значения с типом ДанныеФормыСтруктура или ДанныеФормыКоллекция нельзя, так как при возврате из процедуры или функции будет производится попытка их перезаписи, что недопустимо. Чтобы такого не происходило, можно, например, в вызываемой процедуре или функции указать ключевое слово «Знач», которое будет означать, что параметр будет передан как значение, а не ссылка и ошибки уже не будет. Но в любом случае нужно смотреть, какая реализация кода будет более оптимальной, возможно, что передача массива строк из табличной части будет более производительнее.
Если данная тема будет востребована, то продолжение точно напишу.
(5) Спасибо. Тоже появилась такая мысль после того как сделал через массив, но проверять не стал. Думал еще капнуть в сторону КопированиеДанныхФормы, но в этом случае непонятно как программно создать приемник.
(6)
копируете объект формы в переменную, передаете на сервер, там делаете заполнение, при выходе из процедуры заполнения, осуществляете копирование через «КопированиеДанныхФормы».
(7) Скорее всего копировать объект формы целиком и гонять его с клиента на сервер и обратно должно быть накладно. Так то можно и через сериализацию данные перегнать. Стоит ли оно того.
(8) Я лишь привела пример одного из вариантов решения задачи.
(8)Экспериментировал с простыми вычислениями (типа 1+1) на клиенте, на сервере или в БД с вызовами между ними
Тут рассмотрены разные варианты взаимодействия клиента и сервера.
Но больше расстроило, что вызов клиентом сервера без контекста (п.1.3.) в 3!!! раза оказался медленнее обращения сервера к БД (п.2.1.).
Оформление отличное и конкретные примеры тоже будут полезны новичкам.
Но название статьи предполагает более концептуальный охват, с которым по моему мнению гораздо лучше справилась статья .
(10) Я это уже заметил достаточно давно. В типовых конфигурациях хорошо видно, как разработчики перекладывают вычислительный функционал на SQL.
(11) Возможно Вы правы и стоило бы более подробно расписать некоторые механизмы, например, «жизненный цикл формы», но я решила не перегружать статью.
Указанная Вами статья включает в себя не на много много больше информации («и воды там достаточно») и читать, ИМХО, ее было тяжело. Также, стоит заметить, что автор не пытался раскрыть тему оптимизации, а лишь рассказывал, что представляют из себя управляемые формы.
Считаю, что для базовой основы, информации здесь вполне достаточно, единственное, думаю стоило бы добавить еще несколько примеров в конце.
Спасибо! Но не совсем понял ремарку- «Не рекомендуется создавать клент-серверные общие модули»?
(14)
Если для процедуры в клиент-серверном общем модуле не указать директиву, то процедура будет скомпилирована в обоих контекстах, при этом надо следить, чтобы код в этой процедуре был написан с учетом его доступности в контекстах модуля. Также, немало важным является то, что процедура на клиенте из общего модуля может обратиться только к экспортной процедуре серверного общего модуля с галочкой «вызов сервер», т.е. расположить в одном общем модуле процедуры НаКлиенте и НаСервере с вызовом друг друга, как например в модуле форм, не получится. Поэтому общие модули разделяют на Клиентские и на Серверные, а вот клиент-серверные используются не часто, для каких то общих действий, например, для простых вычислительных операций.
(15)
Или для подписок на события…
(16) В общих модулях происходит определение процедур и функций, которые требуются для выполнения каких-то действий. Подписки, сами по себе не содержат код, а обращаются к процедурам из общих модулей, поэтому не совсем корректно говорить о том, что клиент-серверные общие модули используются для подписок.
Если заглянуть в типовые общие модули, то можно увидеть, что там производятся какие-то общие простые операции, например, определение типов значений, работа с числами, строками, массивами и с теми встроенными процедурами/функциями, которые доступны и на клиенте и на сервере.
(14) Я понял ее как «Не рекомендуется создавать клент-серверные общие модули, все равно вы не умеете их готовить«
(17)
А что же используется?
Подписка — всего лишь триггер для выполнения куска кода, этот кусок кода можно расположить где-нибудь кроме общего модуля?
А теперь представим подписку ПередЗаписью для справочника, и запись этого справочника выполняется в фоновом задании (Сервер), в толстом клиенте и еще во внешнем соединении.
Если флажки (все три) на ОМ стоять не будут — будет «красный крест», нет?)
(19) Да при чем тут вообще подписки, если речь шла про процедуры и функции, с которыми могут возникнуть проблемы, если в них что-то не так написать или поставить не те галочки у общего модуля? Поэтому и написала, что в контексте моего сообщения, говорить про подписки было бы некорректно.
(20)
Подписки — часть общих модулей, как и (например) регламентные задания. И в клиент-серверном режиме — поведение отличается.
Это точно такие же процедуры как и все остальные
Статья называется «Основные понятия и механизмы клиент-серверного взаимодействия в 1C» — мне показалось, что особенности поведения РЗ и триггеров должны быть включены (или хотя бы упомянуты)
Тем более, что идет пояснение вашей фразы «Не рекомендуется создавать клент-серверные общие модули» и вашего ответа «а вот клиент-серверные используются не часто», и в качестве примера выприводите только вычисления, я всего лишь уточнил, что модули с флагами клиент и сервер имеет смысл так же создавать для реализации подписок на события (и для начинающих — это наверное, важная инфо про КС механику)
Возможно, я неверно истолковал название статьи, и название должно интерпретироваться как «Особенности работы с управляемыми формами» или «Особенности оптимизации работы управляемых форм в клиент-серверном режиме», no aggression
(21)
чтобы произвести какие-то простые действия, например вычисления)
(21)
скорее не Вы неправильно истолковали, а я наверно неправильно назвала статью и ее действительно надо было назвать по-другому, потому что акцент сделан именно на механизмы оптимизации.
Небольшой косячок в тексте
Очень напоминает выдержки из книги «Разработка интерфейса прикладных решений на платформе «1С:Предприятие 8». Примеров оптимизации приведено всего два, в книге намного больше.
ДанныеРеквизитов.Вставить(«Артикул»,Ссылка.Артикул);
ДанныеРеквизитов.Вставить(«ЕдиницаИзмерения»,Ссылка.ЕдиницаИзмерения);
Это капец, да.
А использовать ОбщегоНазначения.ЗначенияРеквизитовОбъекта() не по-пацански.
ДанныеРеквизитов = ОбщегоНазначения.ЗначенияРеквизитовОбъекта(Ссылка, «Артикул, ЕдиницаИзмерения»);
могу только отминусовать автора за то что статья по факту практически видоизменено с ИТС. Это смешно как слова перековерканы но смысл с книжки 1в 1. Особенно ЗАКЛЮЧЕНИЕ. Модераторы следует обратить на это внимание.
Кому лень читать, вся статья сводится к двум советам: Если у тебя много серверных вызовов, попробуй уменьшить их количество. Не тащи на сервер весь контекст формы без необходимости, это как минимум глупо. Собственно все. Вместо вступительной теоретической части, стоит просто оставить тут у автора получилось подробнее и лучше, хотя можно просто оставить эту ссылку, добавлять ничего не надо, все, что написано в этой статье, больше и интереснее, есть по ссылке. Про использование ключевого слова «Знач» при передаче данных на сервер сознательно не стали упоминать?
(26)
позвольте Вас спросить, а Вы наверно черпаете знания «с потолка»? Конечно же был прочитан не один материал, включая и ИТС, прежде чем появилась данная статья, в которой как раз и попыталась собрать в кучу все ключевые, как мне показалось, моменты.
видимо заключение для Вас явилось прям каким-то камнем преткновения, раз решили заминусовать статью))
А вообще да, идея была взята из книги «Разработка интерфейса прикладных решений на платформе 1С:Предприятие 8», где все подробно расписано, но не каждый захочет ее прочитать всю. Моей ошибкой было не указать ее в тексте, критика ведь для этого и нужна, чтобы выявлять ошибки)
(25)
как Вы могли заметить, про этот «капец» в статье есть пояснение, что через точку лучше не обращаться к данным базы, если конечно Вы это имели ввиду.
А по поводу
в статье ведь не разбирается использование стандартных функций БСП.
(28) минус схлопотали из-за того, что статья эта не собственная и очень много буковок именно из этой книги. Значит и следовательно статью требовалось назвать как-то иначе и в обязательном характере упомянуть основной источник. Ведь даже примеры от туда только скрины другие. смешно не иначе.
ЗЫ, На будущее сравните написание статей других авторов. Я не понимаю зачем делать копи пасты из книги и менять состав слов и говорить это мой труд!?
Вот что не сказать про эту статью раскрыто намного больше и собственной терминологией, а не книжной из ИТС. Поэтому однозначно МИНУС.
Автор скорее всего хотела сказать «передача данных с сервера на клиент»
(31) Я еще думала, может написать по другому, возможно моя формулировка будет непонятна, смысл то получается одинаковый)
(30)
Ну, как говорится, для всех мил не будешь. Поставили минус, Ваше право, но я останусь при свое мнении, что вычленение чего-то существенного из общей массы текста и перефразирование в более понятный язык для начинающих — это тоже труд.
(10) можете скинуть свою обработку для теста?
Уменьшается ли объем данных (трафик) ответа сервера клиенту если использовать для параметров «Знач» при клиент-серверном вызове серверной функции?
(35)
конечно уменьшаются, данные обратно на клиент не поедут.
Благодарю за обсуждение и ответ, как новичку в 1с было полезно прочитать ответы, хотя некоторые аспекты до конца мне не понятны.
Иногда лучше вызывать сервер, без лишний обрашений. Так как при первом обращение объект кешируется 1с (так написано на сайте ИТС в разделе разработчики.)
Оптимизация 1с сводится к правильному написанию кода, особенно запросы, а клиент сервер это все мелочи, которые не заметишь на производительности.
(32) совсем не одинаковый!
Нельзя передать данные на клиент по желанию сервера без системы взаимодействия!
одним вызовом возвращать больше данных из номенклатуры, это логично.
по сути весь смысл статьи — чем меньше вызовов сервера, тем лучше. больше кэшируем данных, используем функции с повт. использованием. НаСервереБезКонтекста > НаСервере.
по поводу БСП — общегоназначениясервер постоянно дергает метаданные, собирает запрос. может быть накладнее отдельной процедуры. но это мы уже в спор о балансе оптимизации / рефакторинга.
(4) Отличная статья. Было бы здорово увидеть продолжение про «передачу разных типов данных между клиентом и сервером»
(41) Спасибо. К сожалению график работы пока не позволяет заниматься чем-то, кроме работы.