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

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

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

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

1. Многие конфигурации 1С имеют несколько интерфейсов . Причем они могут сильно отличаться. Потому что разным пользователям программ требуется разный функционал в соответствии с решаемыми задачами. Рядовому бухгалтеру не нужен (и даже опасен) полный интерфейс главного бухгалтера. Или менеджеру по продажам не нужен интерфейс менеджера по закупкам или кассира.

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

3. Часто бывает, что одну и ту же операцию можно выполнить разными путями . Один и тот же справочник или документ можно найти в 1 С в нескольких разных разделах меню или панели функций, а одну и ту же команду — выполнить через меню или с помощью некоторой комбинации клавиш.

Как изменить интерфейс в 1С

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

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

Важным аспектом обучения 1С на является понимание сути учетных механизмов Бухгалтерии 8.2, а не простое выполнение учетных операций в программе.

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

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

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

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

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

Как такового меню «Операции» в бухгалтерии 3.0 нет. Его аналог называется «Все функции» и по умолчанию отображение этого раздела в программе не установлено. Чтобы включить его надо войти в меню, которое открывается с помощью оранжевой кнопочки с треугольником в верхнем левом углу программы. В появившемся списке выбрать раздел «Сервис» и открыть раздел «Параметры».

В открывшемся окне устанавливаем флажок «Отображать команду «Все функции» и закрепляем результат нажатием кнопки «Применить».

Теперь в том же Главном меню (оранжевая кнопка с треугольником) мы видим раздел «Все функции»

В котором все то, что мы так привыкли видеть в Бухгалтерии 2.0 в разделе «Операции»:

2) Теперь рассмотрим возможности программы в плане настройки интерфейса ТАКСИ. Например, сейчас у меня программа выглядит вот так:

Т.е. разделы сверху. Открытых окна в закладках внизу. Давайте посмотрим как изменить расположение всех элементов рабочего окна программы. Опять открываем главное меню и находим там раздел «Настройка панелей».

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

Нажимаем кнопку «Применить» или «Ок» и вуа-ля, вот как стала выглядеть наша программа:

Возможно, кому-то так работать будет удобнее.

3) Еще один совет по настройке программы. Как правило, у каждого бухгалтера есть какие-то разделы или отчеты, которыми он пользуется ежедневно. Ну, например, ОСВ или ОСВ по счету. И было бы очень удобно, если они будут всегда рядом, всегда под рукой. Этого можно добиться весьма простым приемом, поместив необходимые отчеты в раздел «Избранное». Найдем в разделе «Отчеты» оборотно-сальдовую ведомость. Наведя на нее указать мыши, мы видим рядом серую звездочку.

Кликнув по ней, мы отметим выбранный отчет как «Избранное»

Раздел «Избранное» с помощью уже известного нам редактора панелей поместим, например, внизу рабочего окна программы.

4) И еще один «секрет» по настройке интерфейса программы. В различных разделах программы есть документы, которыми некоторые не пользуются никогда. Ну, просто в силу специфики деятельности организации. Например, в разделе «Покупки» документы, связанные с ЕГАИС.

Эти документы нам не нужны и можно убрать их с рабочего стола. Для этого в редактируемом разделе в правом верхнем углу нажимаем на шестеренку и в появившемся меню выбираем пункт «Настройка навигации»

В появившемся окне мы видим две колонки. Слева-команды которые можно добавить на наш рабочий стол. А справа, те команды которые есть на нашем рабочем столе. Находим с правой колонке раздел ЕГАИС и нажимаем на кнопку «Удалить»

Соответственно, документы которые находятся в правой колонке можно добавить на рабочий стол по кнопке «Добавить»

5) Ну и напоследок, для тех, кто никак не хочет привыкать к интерфейсу «Такси». Можно изменить интерфейс на тот, который был в первых версиях бухгалтерии 3.0.

В разделе «Администрирование» находим пункт «Интерфейс»

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

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

Для интереса посмотрим, что же такое интерфейс, аналогичный Бухгалтерии 7.7.

Ну не знаю, не знаю. Я пожалуй вернусь к привычному для меня «Такси».

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

Подсистема в 1С 8.3 — объект древа метаданных, который отвечает за построение командного интерфейса конфигурации.

Ниже в статье речь пойдет о подсистемах начиная с версии 8.2.

Дело в том, что в версии 8.1 (как и для обычного приложения 8.2) тоже были подсистемы, но они служили совершенно для других целей, скорее, для разработчика, чем для пользователя. С помощью подсистем в 8.1 обычно разделяли разный функционал. Также подсистемы помогали при объединении разных конфигураций 1С — можно было указать, какую систему переносить.

Подсистемы 1С и интерфейс для программиста

В версиях 8.3 и 8.2 подсистемы — это основной инструмент построения командного интерфейса пользователя. Объекты метаданных «Подсистемы» имеют иерархическую структуру, чтобы настроить «подменю» в интерфейсе, необходимо добавить подчиненную подсистемы:

Свойства и настройки

Рассмотрим настройки и свойства подсистем в конфигураторе:

Получите 267 видеоуроков по 1С бесплатно:

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

Кнопка открывает панель настройки интерфейса, где можно настроить интерфейсы в зависимости от роли текущего пользователя:

Картинка — картинка, назначенная для подсистемы, отображается в режиме предприятия. Можно выбрать стандартную картинку, а можно добавить свою, предварительно создав её как объект конфигурации Картинка:

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

Вкладка Состав определяет набор объектов метаданных, участвующих в данной подсистеме.

На вкладке Прочее можно описать справку к подсистеме и указать настройку Включать в содержание справки — включать ли данный раздел справки в общую справочную информацию по конфигурации.

Если не отображается отчет или обработка в управляемом интерфейсе

Эта проблема очень часто возникает у начинающих разработчиков — вроде отчет или обработка была добавлена в состав подсистемы, а её не видно.

Первая причина этого может в том, что у объекта не задана управляемая форма.

Вторая причина — на вкладке Команды объекта установлена галка «Использовать стандартные команды». Связано это с тем, что для открытия обработки может быть описана как своя процедура, так и использована стандартная:

Публикую вторую главу моей книги «Основы разработки в 1С: Такси»

Глава 2.Обычное и управляемое приложение 1С

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

Что вообще такое «интерфейс»? По сути, это общая граница между двумя взаимодействующими системами (очень часто одной системой является человек). Возьмем, например, автомобиль. Есть ли у него интерфейс? Да, конечно. Но что же является общей границей между автомобилем и человеком? Во-первых, это рабочее место, т.е. непосредственно водительское сиденье и органы управление (руль, педаль акселератора, педаль тормоза и т.д.). Во-вторых, это принципы взаимодействия человека с автомобилем, которые являются каким-то набором правил. Например, для того, чтобы ускорить автомобиль, нужно нажать педаль газа, замедлить – педаль тормоза, для поворота направо нужно выкрутить руль вправо и т.д. Благодаря двум этим сущностям человек может управлять автомобилем. Уберите что-то одно, и управление автомобилем не станет возможным.

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

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

Рис. 1.2.1 Пример командной строки

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

Данный вид интерфейса давно является архаичным, и на его смену пришел графический интерфейс пользователя (анг. graphical user interface GUI). В этом интерфейсе взаимодействие между пользователем и приложением происходит посредством различных графических элементов, нарисованных на дисплее (кнопки, иконки, переключатели и т.п). В графическом интерфейсе оператор имеет произвольный доступ посредством органов управления к любым графическим элементами. В нашем случае, когда автоматизируем складской учет, взаимодействие может выглядеть так: оператор нажимает кнопку «Приход», открывается форма подбора товара, где оператор выбирает нужный товар из списка и вводит его количество. Если нужно осуществить расход, то оператор нажимает кнопку «Расход», так же открывается форма подбора, где оператор так же выбирает нужный товар и вводит его количество. Когда нужно сверить остатки, оператор нажимает на кнопку «Остатки», и программа выводит ему остатки товара на складе. Тем самым с помощью данного графического интерфейса Вы можете вполне успешно вести учет товаров на складе.

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

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

Режим обычного приложения

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

В режиме обычного приложения используется интерфейс и формы, которые применялись в платформах 8.0 и 8.1. Раньше этот режим никак не назывался, сейчас же он называется «режим обычного приложения», а формы, которые используются в этом режиме, называются «обычные формы».

Посмотрим вкратце, как выглядит этот режим. Многим он уже будет знаком, но некоторые, особенно те, кто не застал работу под платформами 8.0 и 8.1, его увидят в первый раз.

После загрузки программы пользователь видит интерфейс с меню в его верхней части (см. рис. 1.2.2).

Рис 1.2.2 Вид интерфейса обычного приложения

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

Рис.1.2.3. Форма списка документов

Из формы списка пользователь может открыть форму документа или справочника (см. рис. 1.2.4).

Рис. 1.2.4. Форма документа

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

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

Рис 1.2.5. Конструирование обычных форм

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

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

Режим управляемого приложения

Так в чем же особенность и кардинальное различие режима управляемого приложения от обычного? Основное отличие — это использование управляемого командного интерфейса и управляемых форм. Разберем каждую из этих сущностей отдельно. Что такое управляемый командный интерфейс? Для того, чтобы ответить на этот вопрос, необходимо углубиться опять в прошлое.

Рассмотрим в самом простом виде, как велась разработка конфигурации в обычном приложении. Сначала мы конструировали бизнес-логику: документы, справочники, отчеты, обработки и их взаимодействие между собой. Потом мы настраивали роли, например пользователь с ролью «Снабженец» имел доступ к документу «Приход товара», а к документу «Расход товара» — нет. И наоборот, пользователь с ролью «Продавец» имел доступ к документу «Расход товара», а к документу «Приход товара» — нет. Следующим шагом мы разрабатывали интерфейсы для каждого вида пользователя. Кто практиковал разработку под обычным приложением, помнит, что был такой объект конфигурации, как «Интерфейс», в котором можно было настроить каждое меню наподобие меню на рисунке 1.2.2. И в нашем случае разработчику нужно было потрудиться сделать два интерфейса: один для снабженца, а другой для продавца. Потому что если бы он разработал один общий интерфейс, в котором можно открыть и документ «Приход товара», и документ «Расход товара», то было бы не совсем правильно, если бы снабженец при попытке отрыть список документов «Расход товара», получил сообщение системы, что у него нет на это прав. Чтобы избежать этого, необходимо было сделать два интерфейса и для каждого пользователя указать, под каким интерфейсом он должен работать.

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

Рис. 1.2.6. Управляемый командный интерфейс

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

Если у какого-то пользователя будет роль, в которой нет прав на просмотр подсистемы, например «Снабжение», то при запуске приложения 1С он просто не увидит этот пункт меню. Так же он не увидит в списке меню документ, на который у него нет права хотя бы на просмотр.

На рисунке 1.2.6 Вы видели интерфейс пользователя с полными правами, а, например, интерфейс продавца будет выглядеть так:

Рис. 1.2.7. Интерфейс пользователя с ограниченными правами

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

Рис. 1.2.8. Интерфейс пользователя с урезанными функциями текущего раздела

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

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

Теперь разберем, что же такое управляемые формы.

Изучите программирование в 1С с помощью моей книги «Программировать в 1С за 11 шагов»

Без сложных технических терминов.
Более 700 страниц практического материала.
Каждое задание сопровождается рисунком (скриншот).
Сборник задач для домашней проработки.
Книга написана понятным и простым языком — для новичка.
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!

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

можно оплатить вручную:

Яндекс.Деньги — 410012882996301
Web Money — R955262494655

Вступайте в мои группы.

И Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

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

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

Толстый клиент (обычный и управляемый режим запуска)
Тонкий клиент
Веб-клиент

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

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

Перечислим директивы компиляции методов формы:

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

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

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

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

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Секция обработчиков событий Метод – наклиенте Метод – насервере Метод - наклиенте Секция служебных процедур и функций Вспомогательные функции управления вводом
Пример 2:
Служебные процедуры и функции Документы оплаты Ценности Обработчики событий
Пример 3:
Служебные процедуры на сервере Служебные процедуры на клиенте Служебные процедуры на сервере без контекста Обработчики событий шапки Обработчики событий команд
Пример 4:
Процедуры общего назначения Обработчики событий формы Процедуры подсистемы «контактная информация»
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

Неинформативные слова «Общие, Служебные, Вспомогательные».
Робкие попытки разделить клиентские и серверные методы.
Часто методы группируются по интерфейсным элементам «Работа с табличной частью Товары, Контактной информацией».
Произвольное расположение методов и групп кода. Например, Обработчики событий могут быть в одной форме вверху, в другой внизу, в третьей вообще не выделены и т.д.
И не будем забывать, что это все в рамках одной конфигурации.
Да бывают конфигурации, в которых слова «Общие, Служебные, Вспомогательные» всегда находятся на одних и тех же местах но…

Зачем нужна структура кода?

Упрощение сопровождения.
Упрощение обучения.
Фиксация общих/важных/удачных принципов.
…ваш вариант

Почему существующий стандарт разработки от фирмы 1С не помогает?

Посмотрим опубликованные на дисках ИТС и в различных «Пособиях разработчика…» принципы, рекомендуемые при написании управляемой формы.

Минимизируйте число серверных вызовов.
Максимум вычислений на сервере.
Неконтекстные вызовы сервера быстрее контекстных.
Программируйте с учетом клиент-серверного взаимодействия.
и т.п.

Это лозунги, абсолютно верные, но как их реализовать? Как минимизировать число вызовов, что значит программировать в клиент-серверном режиме?

Шаблоны проектирования или мудрость поколений

Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.

Remote Facade (далее Интерфейс удаленного доступа)
Data Transfer Object (далее Объект переноса данных)

Слово Мартину Фаулеру , его описание данных принципов:

… каждый объект, потенциально предназначенный для удаленного доступа, должен иметь интерфейс с низкой степенью детализации , что позволит максимально уменьшить количество вызовов, необходимых для выполнения определенной процедуры. … Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта.…Запомните: интерфейс удаленного доступа не содержит логики домена .
…если бы я был заботливой мамой, то обязательно сказал бы своему ребенку: «Никогда не пиши объекты переноса данных!» В большинстве случаев объекты переноса данных представляют собой не более чем раздутый набор полей … Ценность этого омерзительного монстра состоит исключительно в возможности передавать по сети несколько элементов информации за один вызов - прием, который имеет большое значение для распределенных систем.

Примеры шаблонов в платформе 1С

Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
ПараметрыОткрытия = Новый Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = ОткрытьФорму(ИмяФормы, ПараметрыОткрытия);
Сравните с принятым в v8.1 стилем.
Форма = ПолучитьФорму(ИмяФормы); Форма.Параметр1 = Значение1; Форма.Параметр2 = Значение2; Форма.Открыть();

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

ДанныеФормыСтруктура
ДанныеФормыКоллекция
ДанныеФормыСтруктураСКоллекцией
ДанныеФормыДерево

Преобразование системных объектов переноса данных в прикладные типы и обратно выполняется методами:

ЗначениеВДанныеФормы()
ДанныеФормыВЗначение()
КопироватьДанныеФормы()
ЗначениеВРеквизитФормы()
РеквизитФормыВЗначение()

Часто явное преобразование используется при адаптации существующего решения. Методы могут ожидать (использовать особенности) входные параметры, например ТаблицаЗначений, а не ДанныеФормыКоллекция, или метод был определен в контексте прикладного объекта и стал недоступен для прямого вызова из формы.
Пример 1С v8.1:
// на клиенте в контексте формы ЗаполнитьКэшПользователей(ПодразделениеСсылка)
Пример 1С v8.2:
// на сервере в контексте формы ОбработкаОбъект = РеквизитФормыВЗначение("Объект"); ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка); ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

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

Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
&НаСервереБезКонтекста Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус) Ошибки = Новый Соответствие(); // [заказ][описание ошибки] Для Каждого Заказ Из Заказы Цикл НачатьТранзакцию(); Попытка ДокОб = Заказ.ПолучитьОбъект(); …. другие действия, возможно не только с заказом… Исключение ОтменитьТранзакцию(); Ошибки.Вставить(Заказ, ОписаниеОшибки()); КонецПопытки; КонецЦикла; Возврат Ошибки; КонецФункции // СерверИзменитьСтатусЗаказов()

Структурируем код

Главные цели, которые должен отражать модуль управляемой формы и подходы к решению.

Четкое разделение клиентского и серверного кода. Не будем забывать, в момент выполнения это два взаимодействующих процесса, в каждом из которых существенно отличается доступный функционал.
Четкое выделение интерфейса удаленного доступа, какие методы сервера можно вызывать с клиента, а какие нельзя? Названия методов удаленного интерфейса начинаются с префикса «Сервер». Это позволяет, читая код сразу видеть переход управления на сервер, и упрощает использование контекстной подсказки. Отметим, что официальная рекомендация (ИТС) предлагает именовать методы с постфиксами, например, так ИзменитьСтатусЗаказовНаСервере(). Однако повторим не все серверные методы можно вызывать с клиента, и поэтому более важна логическая доступность, а не место компиляции. Поэтому префиксом «Сервер» отмечаем только методы доступные для клиента, метод-пример назовем СерверИзменитьСтатусЗаказов().
Удобочитаемость. Дело вкуса, принимаем порядок, когда модуль начинается с процедур создания формы на сервере и методов удаленного доступа.
Сопровождаемость. Должно быть однозначно определено место для добавления нового кода. Важный момент, автоматически создаваемые конфигуратором заготовки методов добавляются в конец модуля. Т.к чаще всего автоматически создаются обработчики событий элементов формы, то соответствующий блок расположен последним, чтобы не перетаскивать каждый обработчик в другое место модуля.

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

Графический вариант – наглядно показывает основной поток выполнения.
Текстовый вариант - это пример оформления шаблона для быстрой вставки структуры в новый модуль формы.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Дата=""/> // <Описание> // // //////////////////////////////////////////////////////////////////////////////// // ПЕРЕМЕННЫЕ МОДУЛЯ //////////////////////////////////////////////////////////////////////////////// // НА СЕРВЕРЕ //******* СОБЫТИЯ НА СЕРВЕРЕ ******* &НаСервере Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) //Вставить содержимое обработчика КонецПроцедуры //******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА ******* //******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА //////////////////////////////////////////////////////////////////////////////// // НА КЛИЕНТЕ //******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ ******* //******* КОМАНДЫ ******* //******* СОБЫТИЯ НА КЛИЕНТЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

Связанные вопросы

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

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