К каким объектам базы данных можно обратиться на клиенте 1с

Обновлено: 04.07.2024

В модели разработки прикладных решений 1С:Предприятия для ряда сущностей предметной области используется объектный подход манипулирования данными.

Эти сущности описываются в конфигурации объектами метаданных:

ПланВидовХарактеристик;
ПланСчетов;
ПланВидовРасчета.

С точки зрения модели данных 1С:Предприятия, в базе данных для этих сущностей хранятся объекты.

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

Справочник хранится в таблице. Запись (строка) таблицы определяет объект базы данных – элемент справочника. Но объект базы данных включает не только запись в основной таблице справочника, но и все записи всех табличных частей справочника, относящиеся к данному объекту. Таким образом, объект базы данных включает в себя:

запись основной таблицы;
записи табличных частей.

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

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

Тип СправочникиМенеджер

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

Тип СправочникМенеджер

Тип СправочникМенеджер предоставляет доступ к общим действиям, относящимся к конкретному справочнику . С помощью его методов выполняются действия, относящиеся к справочнику, а не к его конкретным объектам, например:

создать новый объект справочника;
найти объект справочника по коду, и т.д.

Данный менеджер является своего рода "точкой входа" в конкретный справочник в объектной модели встроенного языка.

Объекты типа СправочникиМенеджер и СправочникМенеджер имеются в системе в единственном экземпляре.

Тип СправочникСсылка

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

Значение типа СправочникСсылка – хранит ссылку, идентифицирующую объект в базе данных 1С.

Фактически значение СправочникСсылка хранит только внутренний идентификатор, хранящийся в поле Ссылка таблицы справочника. Это значение:

хранится в полях других таблиц базы данных,
выбирается в поле ввода,
указывается в параметрах запроса при поиске по ссылке и т.д.

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

Тип СправочникОбъект

Значение типа СправочникОбъект используется (в основном):

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

Для одного и того же элемента справочника можно получить несколько объектов типа СправочникОбъект:

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

СправочникОбъект оптимизирует запись изменений в базу данных, например:

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

Т.о. для манипулирования справочником во встроенном языке существуют два основных типа СправочникСсылка.ХХХХ и СправочникОбъект.ХХХХ , где ХХХХ — имя справочника в метаданных.

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

Отличие типов СправочникСсылка и СправочникОбъект:

значение типа СправочникСсылка хранит ссылку, идентифицирующую объект в базе данных;
значение типа СправочникОбъект позволяет считывать и записывать данные объекта.

И СправочникСсылка, и СправочникОбъект предоставляют доступ через свойства к данным объекта - значениям полей таблицы. Однако это происходит совершенно по-разному, так как назначение и использование этих типов принципиально отличается:

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

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

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

Оптимистическая и пессимистическая блoкировка объекта

Для объектов обеспечивается оптимистическая блокировка : объект не может быть записан, если он был изменен в базе данных после считывания.

Этот механизм обеспечивает логическую целостность изменения объектов. Каждый, кто меняет объект, может быть уверен, что его изменения не "затрут" изменений сделанных другими пользователями (сессиями) или другими объектами в этой же сессии. Такая блокировка не препятствует изменению объекта другими сессиями или этой сессией. Однако если с момента считывания объекта и до попытки его записи объект был изменен в базе данных, то запись не будет выполнена.

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

Тип СправочникВыборка

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

ВАЖНО! Выборка всегда считывает данные объектов целиком (все поля и все табличные части).

Тип СправочникСписок

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

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

Рисунок отсюда , там же можно почитать подробнее.

На схеме показаны не все возможные объекты и взаимосвязи. Например, метод Скопировать () существует не только у объекта СправочникСсылка, но и у самого объекта СправочникОбъект. Кроме того, у объекта СправочникМенеджер есть методы НайтиПоНаименованию () и НайтиПоРеквизиту (), которые действуют аналогично методу НайтиПоКоду и возвращают ссылку на найденный элемент или пустую ссылку, если элемент не найден. Также на схемах не показаны специфические объекты и объекты типа "Список".

Свойства и методы прикладных объектов

Менеджер прикладных объектов данного типа

СправочникиМенеджер
ДокументыМенеджер
КонстантыМенеджер
РегистрыНакопленияМенеджер
ОтчетыМенеджер
ОбработкиМенеджер

Объекты данного вида обеспечивают доступ к менеджерам конкретного прикладного объекта.

Обычно доступ к таким объектам производится через свойства глобального контекста, например, Справочники.Сотрудники, Документы.Счет, РегистрыСведений.КурсыВалют и т.д.

Эти объекты являются коллекциями значений и позволяют перебрать свои элементы с помощью цикла "Для Каждого".

Менеджер прикладного объекта

СправочникМенеджер
ДокументМенеджер
КонстантаМенеджер
РегистрНакопленияМенеджер
ОтчетМенеджер
ОбработкаМенеджер

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

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

Типичные свойства (для справочников и планов):

Выбрать()
НайтиПоКоду()
НайтиПоРеквизиту()
ПустаяСсылка()
СоздатьЭлемент()
СоздатьНаборЗаписей()
ПолучитьМакет()
ПолучитьФорму()

СправочникСсылка
ДокументСсылка
ПланСчетовСсылка
ПланВидовРасчетаСсылка

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

Ссылки хранятся в реквизитах, ссылающихся на элементы данного прикладного объекта, например, в реквизите "Сотрудник" документа "ПриемНаРаботу" хранится ссылка на конкретный элемент справочника "Сотрудники".

Заметьте, что у записей регистров нет ссылок.

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

<реквизит>
<табличная часть>
ПометкаУдаления
Дата
Предопределенный
Ссылка

Пустая()
ПолучитьОбъект()
ПолучитьФорму()
Метаданные()
Скопировать()

СправочникВыборка
ДокументВыборка
ЖурналДокументовВыборка
РегистрНакопленияВыборка

Этот объект предоставляет возможность обхода (перебора) объектов базы данных. Например, можно перебрать элементы справочника или перебрать документы, входящие в конкретный журнал.

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

Свойства аналогичны свойствам объекта типа "Ссылка".

СправочникОбъект
ДокументОбъект
ПланСчетовОбъект
ОтчетОбъект
ОбработкаОбъект

Предоставляет доступ к элементу с возможностью записи изменений в базу данных. Этот объект содержит методы, влияющие на элемент в базе данных, например, методы Записать и Удалить.

Для отчетов и обработок через этот объект обычно осуществляется формирование отчета или выполнение обработки.

Если в модуле прикладного объекта (не путать с модулем формы) есть экспортируемые переменные модуля или процедуры/функции, то они дополняют набор свойств и методов именно этого программного объекта.

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

Свойства аналогичны свойствам объекта типа "Ссылка".

Записать()
Удалить()
Заблокировать()
Разблокировать()
Заблокирован()
Скопировать()
ПолучитьФорму()
ПолучитьМакет()
Метаданные()

СправочникСписок
ДокументСписок
ЖурналДокументовСписок
ПланСчетовСписок
РегистрНакопленияСписок
КритерийОтбораСписок

Этот программный объект предназначен для управления списком элементов в табличном поле. Позволяет управлять колонками, отбором и сортировкой в списке.

Этот объект нельзя создать программно, он создается системой автоматически при размещении на форме табличного поля. Конечно, программно можно создать табличное поле в экранной форме и тогда будет создан объект данного типа.

Набор записей

РегистрСведенийНаборЗаписей
РегистрНакопленияНаборЗаписей
РегистрБухгалтерииНаборЗаписей
РегистрРасчетаНаборЗаписей
ПоследовательностьНаборЗаписей

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

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

Добавить()
Удалить()
Очистить()
Записать()
Прочитать()
Количество()
Выгрузить()
Загрузить()

РегистрСведенийЗапись
РегистрНакопленияЗапись
РегистрБухгалтерииЗапись
РегистрРасчетаЗапись

Обеспечивает доступ к одной записи из набора, для того чтобы установить ее измерения, ресурсы и т.д. Этот объект возвращается методами других объектов, например, методом Добавить у объекта типа РегистрНакопленияНаборЗаписей.

Объект типа "Запись" не является постоянным идентификатором конкретной записи регистра, наподобие объекта "Ссылка" для справочников и документов. У записей регистра сведений вообще нет неизменяемого во времени идентификатора и каждая запись регистра однозначно определяется значениями своих измерений (включая системные, например, Период, Регистратор, НомерСтроки)

<измерение>
<реквизит>
<ресурс>
Активность
Период
Регистратор
НомерСтроки
ВидДвижения

Ключ записи

РегистрСведенийКлючЗаписи
РегистрНакопленияКлючЗаписи
РегистрБухгалтерииКлючЗаписи
РегистрРасчетаКлючЗаписи

Типичные свойства (кроме регистра сведений):

Свойства для регистра сведений:

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

Для отправки комментария вам необходимо авторизоваться.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Модель базы данных «1С:Предприятия 8» имеет ряд особенностей, отличающих ее от классических моделей систем управления базами данных (например, основанных на реляционных таблицах), с которыми имеют дело разработчики в универсальных системах.

Основное отличие заключается в том, что разработчик «1С:Предприятия 8» не обращается к базе данных напрямую. Непосредственно он работает с платформой «1С:Предприятия 8». При этом он может:

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

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

Общая система типов

Важной особенностью работы с базой данных является то, что в «1С:Предприятии 8» реализована общая система типов языка и полей баз данных. Иными словами, разработчик одинаковым образом определяет поля базы данных и переменные встроенного языка и одинаковым образом работает с ними.

Этим система «1С:Предприятие 8» выгодно отличается от универсальных инструментальных средств. Обычно, при создании бизнес-приложений с использованием универсальных сред разработки, используются отдельно поставляемые системы управления базами данных. А это значит, что разработчику приходится постоянно заботиться о преобразованиях между типами данных, поддерживаемыми той или иной системы управления базами данных, и типами, поддерживаемыми языком программирования.

Хранение ссылок на объекты

При манипулировании данными, хранящимися в базе данных «1С:Предприятия 8», зачастую используется объектный подход. Это значит, что обращение (чтение и запись) к некоторой совокупности данных, хранящихся в базе, происходит как к единому целому. Например, используя объектную технику, можно манипулировать данными справочников, документов, планов видов характеристик, планов счетов и т.д.

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

Эта ссылка также хранится в поле базы данных, вместе с остальными данными объекта. Кроме того, ссылка может быть использована как значение какого-либо поля другого объекта. Например, ссылка на объект справочника Контрагенты может быть использована как значение соответствующего реквизита документа Приходная накладная.

Составные типы

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

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

Хранение любых данных как Хранилище значения

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

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

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

Создание и обновление структур данных на основе метаданных

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

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

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

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

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

Объектный / табличный доступ к данным

Штатной возможностью «1С:Предприятия 8» является поддержка двух способов доступа к данным — объектного (для чтения и записи) и табличного (для чтения).

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

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

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

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

Немного теории о стороне выполнения кода. При работе 1С в режиме клиент-сервера, запускается несколько процессов. На компьютере пользователя запускается 1cv8.exe, на сервере 1С запускается rphost.exe, rmngr.exe и ragent.exe.

ragent.exe

Приложение ragent.exe это по сути и есть наша служба агента 1С, которую мы можем посмотреть в списке служб Windows. Данное приложение отвечает за запуск всех остальных приложений и за распределение нагрузки между рабочими rphost.

rphost.exe

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

rmngr.exe

В общем случае данное приложение отвечает за выполнение регламентных заданий.

Сторона выполнения кода

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

&НаКлиенте

Код выполняется на том компьютере, за которым сидит пользователь и под теми правами, которые есть у пользователя. Файлы, созданные в процедурах &НаКлиенте будут созданы на пользовательском компьютере. Есть множество ограничений выполнения кода &НаКлиенте, например, здесь нельзя обращаться к СУБД. Это значит нельзя использовать как прямое создание запроса, так и косвенный запрос при обращении к ссылке через точку. Компьютер клиента может быть медленнее сервера, это следует учитывать при написании кода.

&НаСервере

Код выполняется на сервере 1С, в процессе rphost. Файлы, созданные в процедурах &НаСервере, будут сохранены на сервере и смогут быть записаны только в те папки, на которые у пользователя службы агента 1С есть доступ на запись. &НаСервере уже можно свободно писать запросы, обращаться к предопределенным данным и к реквизитам ссылки через точку.

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

Это самый интересный вариант, разберемся для начала, что такое контекст формы. Управляемая форма представляется на уровне платформы в виде XML файла описания расположения элементов и значения реквизитов формы. Соответственно, чем больше элементов на форме и чем больше данных хранится в реквизитах формы, тем больше будет контекст.

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

И вот здесь нам как раз может помочь директива &НаСервереБезКонтекста.

В данном примере произойдет следующее: описание формы, таблица значений с 100000 строк и реквизит1 будут преобразованы в XML, отправлены на сервер. На сервере будет выполнен небольшой неявный запрос к СУБД, в значение реквизит1 будет записан результат этого запроса, все данные опять преобразуются в XML и отправятся на сервер. Учитывая, что таблица значений очень большая, то получится, что мы большой объем данных дважды в холостую передали между клиентом и сервером. Это не оптимально.

Во втором примере мы не стали передавать контекст формы, в итоге произошла только передача ссылки на элемент перечисления с сервера на клиент.

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

Пример 3, предположим, у нас есть название для перечисления, которое хранится в реквизите Реквизит2, мы можем его передать в качестве параметра функции:

Ну и напоследок еще один пример, как делать не надо:

Если мы в качестве параметра передаем ЭтаФорма, то по факту мы внеконтекстный вызов превращаем в контекстный. Если без этого не обойтись, то стоит делать контекстный вызов.

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

Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере.

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

Немного базовой теории

Перед тем, как перейти к содержательной части, договоримся о некоторых ограничениях:

Далее, освежим в памяти немного теории.

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

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

Опережая вопрос «Для чего же директива с самым длинным названием, если она ограничивает и использование контекста форм, и обращения к базе данных?», напомню: любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

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

Теперь про серверный вызов

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

Всё очень просто:

Обратите внимание, что доступ к базе данных есть только на серверной части, а соединение между клиентом и сервером имеет ограниченную пропускную способность. Это и неудивительно – ведь соединение между клиентской и серверной частью может быть установлено даже по нестабильному низкоскоростному каналу связи (например, посредством мобильного интернета).

Кроме этого, передача данных между клиентом и сервером возможна только посредством серверного вызова.

Видим, что на стороне клиента у нас будут доступны процедуры и функции, написанные под двумя директивами из четырёх, а на стороне сервера – под тремя из четырёх.

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

И в этом нам помогут наши новые друзья, знакомьтесь!

Это процесс клиентской части приложения «1С:Предприятие 8». Он запускается на компьютере пользователя и сожительствует в оперативной памяти с другими процессами (38 вкладок браузера, поток аудио из социальной сети, telegram и другие). Может порождать серверный вызов.
Это процесс серверной части приложения «1С:Предприятие 8». Он существует на сервере 1С. Знает, какие клиентские сеансы в данный момент запущены, но самостоятельно не может инициировать взаимодействие с ними. Работает с клиентской частью только через полученный от неё серверный вызов. А это серверный вызов. Как было сказано выше, он порождается процессом клиентской части и призван «прислуживать» ему. Он передает запросы со стороны клиента на сторону сервера, а также занимается транспортировкой данных с клиента на сервер и обратно.

Итак, давайте рассмотрим несколько особенностей работы программного кода в «1С:Предприятие 8», написанного под разными директивами.

Действие 1. Открытие пользователем формы с данными.

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

Действие 2. Получение из открытой Пользователем формы дополнительных данных из Базы данных.

После выполнения метода на сервере, весь этот «пакет» транспортируется обратно. Таким образом, форма со всеми элементами и данными дважды проходит через самое узкое место системы.

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

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

Действие 3. Обработка данных табличной части формы с получением дополнительной информации из Базы данных.

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

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

Явление 2. Предварительная обработка табличной части на стороне клиента с целью подготовки требуемых к обработке на сервере данных и «упаковки» их в набор параметров. Затем передача этого набора на сервер для получения дополнительной информации из базы данных.

В данном случае количество серверных вызовов сведено к минимуму за счёт предварительной подготовки параметров.

Большое количество текущих серверных вызовов может свидетельствовать о неоптимальном программном коде.

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

Действие 4. Выполнение обработки данных.

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

Та-дам!

Для копирования у нас есть ксерокс. Но куда его поставить? На сторону клиента или сервера? Под какой директивой его разместить?

Как было озвучено ранее – любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

Но что произойдёт, если потребность в копировании возникнет на стороне сервера? Например, для подготовки данных, передаваемых на сторону клиента, потребуется сделать копию? Напомню – процесс серверной части не имеет возможности самостоятельно инициировать клиентские вызовы.

Вроде бы результат достигнут – и с сервера, и с клиента доступно копирование. Но для того, чтобы получить копию данных, используемых на клиенте, приходится делать серверный вызов. А это опять ведет к лишней нагрузке на соединение и временным затратам.

Не углубляясь в детали, отметим, что метод, описанный под данной директивой управления, создаётся в двух копиях – и на стороне клиента, и на стороне сервера. Это позволяет выполнить необходимые действия там, где появилась потребность в них (клиент/сервер), без лишних серверных вызовов.

С точки зрения выполнения программы результат будет одинаков. Но объяснение «почему так не надо делать» – это уже совершенно другая тема…

Вместо заключения

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

Придерживайтесь при разработке следующих правил:

По возможности не передавайте контекст формы на сторону сервера
Минимизируйте количество текущих серверных вызовов
Длительные и ресурсоёмкие задачи запускайте на выполнение на стороне сервера (при возможности – в фоновом режиме).

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

Так ли это важно думать об оптимизации? Тут имеет смысл вспомнить одну историю.

Программист Иван при доработке 1С на своём предприятии сделал ошибку в выборе директивы компиляции. Из-за неё длительность одного из серверных вызовов была больше возможной на полсекунды.

Пользователей, применяющих этот функционал, – 25 человек, и каждый из них за рабочий день в среднем совершает 110 таких операций. Всего впустую за рабочий месяц потрачено 28875 секунд (21 рабочий день * 25 человек * 110 операций * 0,5 секунды) = 8,02 часов.

Иван, каково тебе осознавать, что за месяц ты задолжал своему предприятию целый рабочий день?

Читайте также: