1с на клиенте и на сервере что значит
Перейти к содержимому

1с на клиенте и на сервере что значит

  • автор:

Использование директив компиляции и инструкций препроцессора

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

&НаКлиенте (&AtClient)
&НаСервере (&AtServer)
&НаСервереБезКонтекста (&AtServerNoContext)

следует применять только в коде модулей управляемых форм и в коде модулей команд. В остальных модулях рекомендуется применять инструкции препроцессору.

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

2. Не следует использовать инструкции препроцессора в клиент-серверных общих модулях для проверки клиентского и серверного контекстов (#Если Сервер, #Если Клиент) ввиду невозможности надежного определения контекста исполнения. Процедуры и функции, которые работают по-разному при вызове с клиента и с сервера, следует размещать в общих модулях с постфиксами Клиент и Сервер , а не КлиентСервер .

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

Функция КодОсновногоЯзыка() Экспорт
#Если НЕ ТонкийКлиент И НЕ ВебКлиент Тогда
Возврат Метаданные.ОсновнойЯзык.КодЯзыка;
#Иначе
Возврат СтандартныеПодсистемыКлиент.ПараметрКлиента(«КодОсновногоЯзыка»);
#КонецЕсли
КонецФункции

Функция КодОсновногоЯзыка() Экспорт
#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
Возврат Метаданные.ОсновнойЯзык.КодЯзыка;
#Иначе
Возврат СтандартныеПодсистемыКлиент.ПараметрКлиента(«КодОсновногоЯзыка»);
#КонецЕсли
КонецФункции

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

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

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

Процедура Пример1()
а = 1
#Область ИмяОбласти
+ 2;
#КонецОбласти // разрыв выражения
КонецПроцедуры

#Область ИмяОбласти
Процедура Пример2()
// .
#КонецОбласти // разрыв процедуры
КонецПроцедуры

Если <. > Тогда
// .
#Если ВебКлиент Тогда // разрыв блока Если
Иначе
// .
#КонецЕсли
КонецЕсли;

Результат = Пример4(Параметр1,
#Если Клиент Тогда
Параметр2, // некорректный вызов функции
#КонецЕсли
Параметр3);

Данные ошибки диагностируются автоматически с помощью среды разработки 1C:Enterprise Development Tools (EDT).

Инструкции препроцессора «&НаСервереНаКлиенте» и «&НаКлиентеНаСервереБезКонтекста»

Процедуры и функции в модулях управляемых форм, а также в общих клиентских модулях управляемого приложения, требуют четкого определения среды выполнения программного кода.

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

&НаСервереНаКлиенте

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

Изображение

Модуль команды содержит следующий программный код:

Теперь рассмотрим поведение платформы при ее выполнении. Вызовем команду в режиме предприятия и проанализируем количество вызовов сервера. Картина будет следующей:

Изображение

Таким образом, при вызове процедуры с директивой препроцессора «НаКлиентеНаСервере» с клиентской стороны вызова сервера не происходит. Единственный вызов сервера в нашем прмере происходил при обращении к серверной процедуре «Сервер».

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

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

Рассмотрим теперь работу процедур и функций с директивой «&НаКлиентеНаСервереБезКонтекста».

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

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

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

Процедура «Тестируем» принадлежит команде формы. При ее запуске осуществляется вызов процедуры «ТестируемКлиентСервер» с директивой «НаКлиентеНаСервереБезКонтекста». Как было сказано выше, данная процедура не сможет получить доступ к контексту формы и другим клиентским процедурам. Но все серверные процедуры модуля формы без контекста будут доступны для вызова, а также серверные процедуры общего модуля.

Вызов сервера будет произведен, что логично, при вызове серверной процедуры со стороны клиента.

Вывод

Подытожим выше сказанное:

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

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

Базовый принцип программирования управляемой формы в 1С

Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.

  • Толстый клиент (обычный и управляемый режим запуска)
  • Тонкий клиент
  • Веб-клиент
  • Декларативное, а не «по пикселям» описание структуры. Конкретное размещение элементов выполняется системой автоматически при отображении формы.
  • Вся функциональность формы описывается в виде реквизитов и команд. Реквизиты – это данные, с которыми работает форма, а команды – выполняемые действия.
  • Форма выполняется и на сервере и на клиенте.
  • В контексте клиента, недоступны практически все прикладные типы, и соответственно невозможно изменить данные в информационной базе.
  • Для каждого метода или переменной формы обязательно должна быть указана директива компиляции, определяющая, место выполнения (клиент или сервер) и доступ к контексту формы.
  • &НаКлиенте
  • &НаСервере
  • &НаСервереБезКонтекста
  • &НаКлиентеНаСервереБезКонтекста

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

Обозначим проблему

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

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

  • Неинформативные слова «Общие, Служебные, Вспомогательные».
  • Робкие попытки разделить клиентские и серверные методы.
  • Часто методы группируются по интерфейсным элементам «Работа с табличной частью Товары, Контактной информацией».
  • Произвольное расположение методов и групп кода. Например, Обработчики событий могут быть в одной форме вверху, в другой внизу, в третьей вообще не выделены и т.д.
  • И не будем забывать, что это все в рамках одной конфигурации.
  • Да бывают конфигурации, в которых слова «Общие, Служебные, Вспомогательные» всегда находятся на одних и тех же местах но…
Зачем нужна структура кода?
  • Упрощение сопровождения.
  • Упрощение обучения.
  • Фиксация общих/важных/удачных принципов.
  • …ваш вариант
Почему существующий стандарт разработки от фирмы 1С не помогает?
  • Минимизируйте число серверных вызовов.
  • Максимум вычислений на сервере.
  • Неконтекстные вызовы сервера быстрее контекстных.
  • Программируйте с учетом клиент-серверного взаимодействия.
  • и т.п.
Шаблоны проектирования или мудрость поколений
  • Remote Facade (далее Интерфейс удаленного доступа)
  • Data Transfer Object (далее Объект переноса данных)
  • каждый объект, потенциально предназначенный для удаленного доступа, должен иметь интерфейс с низкой степенью детализации, что позволит максимально уменьшить количество вызовов, необходимых для выполнения определенной процедуры. … Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта.…Запомните: интерфейс удаленного доступа не содержит логики домена.
  • …если бы я был заботливой мамой, то обязательно сказал бы своему ребенку: «Никогда не пиши объекты переноса данных!» В большинстве случаев объекты переноса данных представляют собой не более чем раздутый набор полей … Ценность этого омерзительного монстра состоит исключительно в возможности передавать по сети несколько элементов информации за один вызов — прием, который имеет большое значение для распределенных систем.
Примеры шаблонов в платформе 1С

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

Добавить комментарий

Ваш адрес email не будет опубликован.