управляемое приложение или обычное приложение
Управляемое приложение vs Обычное приложение
О системе 1С 
06.07.2017 17:51 
6949Платформа 1С:Предприятие позволяет определять режим запуска конфигураций. Данная настройка «Основной режим запуска» задается в свойствах конфигурации в режиме 1С:Конфигуратор. Это свойство можно установить в «Управляемое приложение» или «Обычное приложение». Управляемое и обычное приложения имеют ряд существенных отличий.
Пример управляемое приложение
Пример обычное приложение
Основные отличия в программировании
В зависимости от выбранного режима накладывается ряд правил для программирования. В управляемом приложении при написании программного кода требуется разделять код на клиентский и серверный с помощью специальных директив. Это обеспечивает полноценную реализацию клиент серверного приложения. В обычном приложении такого нет. Процесс создания форм отличается. В управляемом приложении работают обычные и управляемые формы. В обычном приложении работают только обычные формы.
Основные отличия в пользовательском интерфейсе
Окно конфигурации и формы в управляемом и обычном приложениях сильно отличаются. Поэтому даже в пользовательском интерфейсе можно сразу отличить конфигурации на управляемых и обычных формах. Конфигурации написанные на управляемых формах имеют два варианта оформления: стандартный и такси.
Новые конфигурации разрабатываются на управляемом приложении. Так как данная технология является более оптимизированной с точки зрения производительности. Это достигается благодаря реализации клиент серверной технологии. На рынке уже появились новые альтернативные конфигурации. конфигурации «Бухгалтерия предприятия 2.0» написана в обычном приложении, а «Бухгалтерия 3.0» в управляемом. «Управление торговлей 10.3» в обычном приложении, «Управление торговлей 11» уже в управляемом приложении. И так можно найти еще множество альтернатив обычному приложению.
Для того чтобы добавить сообщение, необходимо Войти или Зарегистрироваться
Управляемые и неуправляемые формы 1с
Обычное приложение 1С (обычные формы, обычный интерфейс, версия 1С 8.2)
В 1С 8.2 возможна работа только с обычными формами, в режиме обычного приложения. На изображении ниже показана база в режиме работы «обычное приложение 1С» (обычные формы).
Управляемое приложение 1С (управляемые формы, управляемый интерфейс, версия 1С 8.3)
С версии платформы 8.2 в 1С стали использоваться новые принципы построения интерфейса и взаимодействия пользователя с базой данных. Новая технология получила название «Управляемое приложение». Наибольшей переработке подверглись механизмы построения форм и схема взаимодействий пользователя сервера 1С и базы данных. Обычный режим все еще поддерживается платформой, но со временем все пользователи 1С перейдут на управляемые формы.
Отличия управляемых форм
Для простых пользователей управляемая форма документа 1С отличается от обычной только внешним видом. Для разработчика же это новый механизм со своими правилами, законами и условиями. Изменению подверглись многие области, но ключевыми среди опытных разработчиков 1С считаются следующие нововведения:
Последний пункт особо остро стоит в режиме управляемых форм. Если разработчик плохо разбирается в директивах или взаимодействии клиента и сервера, то ему будет крайне сложно создать управляемую форму. Все новые принципы построения управляемых форм в 1С:Предприятие 8.3 объединены общим понятием трехзвенной архитектуры. В нее входят клиентские компьютеры, сервер 1С и СУБД, где хранятся данные.
Редактирование управляемой формы в конфигураторе тоже стало отличаться. Изменились многие аспекты и разработчики версии 7.7, где не было управляемых форм, могут быть удивлены. Изменился даже внешний вид конструктора форм, который можно увидеть, открыв любую из форм объекта конфигурации. При открытии объекта мы видим окно, разделенное на несколько разделов:
Разработчики 1С агитируют клиентов перейти на управляемые формы, поэтому изучение принципов разработки управляемых форм – вопрос времени. Начав работать с этим типом форм, вы поймете, что это шаг к стандартизации разработки и соблюдению единых правил. Поэтому способность работать с управляемыми формами в 1С 8.3 увеличивает ваш уровень разработчика 1С.
Принципы разработки управляемых форм
В первую очередь, для понимания механизма управляемого режима 1С следует запомнить, что форма существует и на сервере, и на клиенте. Причем, на клиенте этот объект представляет собой лишь изображение интерфейса взаимодействия пользователя с программой. Все расчеты, алгоритмы, вычисления и обработки должны происходить только на стороне сервера. Это продиктовано не только невозможностью на клиенте пользоваться многими функциями и параметрами, но и требованиями к быстродействию.
Разобраться, где выполняется процедура, можно по наименованию директивы, которая должна быть прописана перед каждой процедурой и функцией в модуле формы. Формулировка «БезКонтекста» показывает, что данные на управляемой форме не будут передаваться в эту процедуру на сервер. Таким образом, в подобных процедурах не получится писать алгоритмы, опирающиеся на значения, которые ввел пользователь. Если эта формулировка не указана, то форма передается целиком со всеми реквизитами, и вы сможете обращаться к ним.
Разработчики 1С настоятельно рекомендуют использовать неконтекстные вызовы сервера, максимально сокращать их количество и стараться не производить вычислений на клиенте. Начинающим разработчикам без теоретической подготовки сложно соответствовать всем этим правилам и изменять код правильно. Перед началом самостоятельной работы полезно будет открыть управляемую форму конфигурации, посмотреть на синтаксис и способы взаимодействия клиента и сервера.
Новые правила разработки форм 1С принесут большую пользу, если все разработчики станут их придерживаться. Причем, изменения к лучшему почувствуют все – и программисты, и компании, работающие в 1С, и фирмы-франчайзи, и разработчики 1С. Основные последствия правильной эксплуатации управляемых форм в 1С:
Выбор управляемой формы в качестве основного режима запуска 1С способен преподнести множество сюрпризов. Но с правильным подходом этот шаг принесет большие дивиденды, поэтому на него решаются все больше пользователей 1С по всей России. С учетом того, что компания 1С в будущем рассчитывает на развитие именно управляемых форм, оставаться на устаревающих обычных рискованно.
Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.
Введение
Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.
В 2008 году стала доступна новая версия платформы 1С: Предприятие 8.2 (далее Управляемое приложение), которая полностью меняет весь слой работы с интерфейсом. Сюда относится и командный интерфейс, и формы, и оконная система. При этом не только меняется модель разработки пользовательского интерфейса в конфигурации, но и предлагается новая архитектура разделения функциональности между клиентским приложением и сервером.
Управляемое приложение поддерживает следующие типы клиентов:
В управляемом приложении используются формы, построенные на новой технологии. Они называются Управляемые формы. Для облегчения перехода прежние формы (т.н. Обычные формы) также поддерживаются, но их функциональность не развивается и они доступны только в режиме запуска толстого клиента.
Основные отличия управляемых форм для разработчика:
Перечислим директивы компиляции методов формы:
Проиллюстрируем перечисленное. На скриншоте пример управляемой формы и ее модуля в режиме разработки. Найдите декларативное описание, реквизиты, директивы компиляции и т.д. 
Все дальнейшие рассуждения будут о правой части иллюстрации, о том, как структурировать код модуля и какие принципы позволят реализовать эффективное клиент-серверное взаимодействие.
Обозначим проблему
Прошло уже несколько лет как новая версия платформы 1С активно используется и выпущено множество решений (конфигураций) как фирмой 1С, так и ее многочисленными партнерами.
Сложилось ли за это время у разработчиков единое понимание принципов клиент-серверного взаимодействия при создании форм, и изменился ли подход к реализации программных модулей в новых архитектурных реалиях?
Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:
Зачем нужна структура кода?
Почему существующий стандарт разработки от фирмы 1С не помогает?
Посмотрим опубликованные на дисках ИТС и в различных «Пособиях разработчика…» принципы, рекомендуемые при написании управляемой формы.
Это лозунги, абсолютно верные, но как их реализовать? Как минимизировать число вызовов, что значит программировать в клиент-серверном режиме?
Шаблоны проектирования или мудрость поколений
Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.
Слово Мартину Фаулеру, его описание данных принципов:
Примеры шаблонов в платформе 1С
Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
Сравните с принятым в v8.1 стилем.
В контексте управляемой формы множество «Объектов переноса данных». Можно выделить системные и определяемые разработчиком.
Системные моделируют на клиенте прикладной объект, в виде одного или несколько элементов данных формы. Создать их вне привязки к реквизитам формы нельзя.
Преобразование системных объектов переноса данных в прикладные типы и обратно выполняется методами:
Часто явное преобразование используется при адаптации существующего решения. Методы могут ожидать (использовать особенности) входные параметры, например ТаблицаЗначений, а не ДанныеФормыКоллекция, или метод был определен в контексте прикладного объекта и стал недоступен для прямого вызова из формы.
Пример 1С v8.1:
Объекты переноса данных, структура которых определяется разработчиком это небольшое подмножество типов доступных и на клиенте и на сервере. Наиболее часто в качестве параметров и результатов методов «огрубленного» интерфейса используются:
Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
Структурируем код
Главные цели, которые должен отражать модуль управляемой формы и подходы к решению.
Ниже приведена базовая структура модуля, реализующая перечисленные цели.
Управляемое приложение или обычное приложение
Есть внешняя обработка, написанная для версии 8.1. Можно ли запустить ее в версии 8.2 так, чтобы работать с ее старой, неуправляемой формой? Обработка нужна всего один раз, для переноса данных, и создавать для нее управляемую форму ради одного раза не хочется.
Для внешних обработок (открываемых из отдельного файла) в управляемом режиме использование обычных форм не поддерживается. Поэтому если в конфигурации, работающей в управляемом режиме, необходимо запустить обработку с неуправляемой формой, и не хочется создавать для этой обработки новую, управляемую форму, то сначала такую обработку нужно включить в состав конфигурации.
Обычные (неуправляемые) формы могут работать только в толстом клиенте. Тонкий и веб-клиенты поддерживают работу только с управляемыми формами.
Поэтому, если нужно открыть обычную форму обработки в управляемом интерфейсе приложения, то это возможно только в толстом клиенте, запущенном в режиме управляемого приложения.
При этом нужно помнить, что запуск клиентов в управляемом режиме возможен только в том случае, если у конфигурации отключена совместимость в версией 8.1 (свойство Режим совместимости ).
Однако этого недостаточно для того, чтобы платформа откорыла старую, неуправляемую форму обработки.
Ну и наконец, у объекта, обычную форму которого вы хотите увидеть в управляемомом режиме, должна существовать единственная основная форма объекта, и эта форма должна быть обычной, неуправляемой. В других случаях (если у объекта нет ни одной основной формы или у объекта есть управляемая основная форма) платформой будет по умолчанию генерироваться или открываться (если она есть) управляемая форма.
Виды программных модулей
В системе 1С:Предприятие существуют несколько видов программных модулей. Они различаются по месту размещения и доступному контексту.
Модуль управляемого приложения
Модуль управляемого приложения располагается в корневом разделе конфигурации. В нем располагаются процедуры-обработчики событий, которые инициализируются при старте и окончании работы системы с установленном в значение «Управляемое приложение» свойства Основной режим запуска. В модуле управляемого приложения возможно объявление переменных, а также объявление и описание процедур и функций, которые будут доступны в любом модуле конфигурации (кроме модуля внешнего соединения). Их доступность также обеспечивается для неглобальных общих модулей с установленным свойством Клиент (управляемое приложение). В контексте модуля управляемого приложения доступны экспортируемые процедуры и функции общих модулей.
Модуль сеанса
Модулем сеанса называется модуль, который автоматически выполняется при старте системы 1С:Предприятие 8 в момент загрузки конфигурации.
Модуль сеанса предназначен для инициализации параметров сеанса и отработки действий, связанных с сеансом работы. Модуль сеанса всегда исполняется в привилегированном режиме в кластере серверов 1С:Предприятия 8.
Важно! Модуль сеанса может содержать только определения процедур и функций.
Модуль сеанса не содержит экспортируемых процедур и функций и может использовать процедуры из общих модулей конфигурации.
Модуль внешнего соединения
Модуль внешнего соединения расположен в корневом разделе конфигурации. В нем располагаются процедуры-обработчики событий, которые инициализируются при старте и окончании работы системы в режиме внешнего соединения (СОМ-соединения).
В модуле внешнего соединения возможно объявление переменных, а также объявление и описание процедур и функций, которые будут доступны для внешнего приложения, а также для неглобальных общих модулей с установленным свойством Внешнее соединение.
Объекты 1С:Предприятия, доступные извне через COM-соединение:
Модуль присутствует только в сессии внешнего соединения.
В данном режиме характерно полное отсутствие пользовательского интерфейса.
Модуль обычного приложения
Модуль обычного приложения располагается в корневом разделе конфигурации. В нем располагаются процедуры-обработчики событий, которые инициализируются при старте и окончании работы системы с установленным в значение «Обычное приложение» свойством Основной режим запуска. В модуле обычного приложения возможно объявление переменных, а также объявление и описание процедур и функций, которые будут доступны в любом модуле конфигурации (кроме модуля внешнего соединения). Их доступность также обеспечивается для неглобальных общих модулей с установленным свойством Клиент (обычное приложение). В контексте модуля обычного приложения доступны экспортируемые процедуры и функции общих модулей.
Общие модули
Общие модули располагаются в отдельной ветке дерева метаданных. Основным назначением общих модулей является содержание общих алгоритмов конфигурации, доступных из разных модулей. В общих модулях отсутствует раздел определения переменных и раздел основной программы, то есть они содержат только раздел процедур и функций (см. раздел «Структура программного модуля»).
В любом общем модуле возможно объявление и описание процедур и функций, которые будут доступны в любом модуле конфигурации.
Если используется клиент–серверный вариант системы 1С:Предприятие 8, то с помощью свойств Клиент (обычное приложение), Клиент (управляемое приложение) и Сервер, а также инструкций препроцессора можно организовывать выполнение различных процедур и функций общих модулей на сервере приложения или на клиентском месте.
Если установлено свойство Клиент (обычное приложение) или Клиент (управляемое приложение), то все процедуры и функции общего модуля могут использоваться в клиентском приложении.
В контексте неглобального общего модуля с установленным свойством Клиент (обычное приложение) доступны экспортируемые переменные, процедуры и функции модуля обычного приложения.
В контексте неглобального общего модуля с установленным свойством Клиент (управляемое приложение) доступны экспортируемые переменные, процедуры и функции модуля управляемого приложения.
Важно! Свойство Клиент (обычное приложение) показывается, если в настройках конфигурации режима запуска установлен режим «Управляемое приложение и обычное приложение«.
Если установлено свойство Сервер, то все процедуры и функции общего модуля могут использоваться в клиент-серверном варианте.
Если предполагается, что процедуры и функции общего модуля могут быть использованы во внешнем соединении, то следует установить свойство Внешнее соединение.
В контексте неглобального общего модуля с установленным свойством Внешнее соединение доступны экспортируемые переменные, процедуры и функции модуля внешнего соединения.
Свойство Вызов сервера разрешает вызов сервера. Свойство доступно, если установлено свойство Сервер. Если не установлено, то процедуры и функции данного модуля доступны только на сервере. Если установлено, то процедуры и функции данного модуля доступны на клиенте.
Свойство Привилегированный предназначено для установки полных прав доступа при выполнении действий с базой данных в процедурах и функциях общего модуля. При установленном свойстве выполнение производится только на сервере.
Повторное использование возвращаемых значений. Свойство доступно, если общий модуль не является Глобальным. Это свойство может принимать следующие значения:
Можно выделить следующие особенности сохранения результатов вызова:
Сохраненные значения удаляются:
Сохраненные значения могут быть удалены:
После удаления значений, вызов экспортной функции выполняется как при первом вызове.
Свойство Глобальный определяет, являются ли экспортируемые методы общего модуля частью глобального контекста.
Если свойство Глобальный установлено в значение Истина, то экспортируемые методы общего модуля доступны как методы глобального контекста.
Если свойство Глобальный установлено в значение Ложь, то в глобальном контексте создается свойство с именем, соответствующим имени общего модуля в метаданных. Данное свойство доступно ТОЛЬКО для чтения. Значением данного свойства является объект ОбщийМодуль. Через данный объект доступны экспортируемые методы данного общего модуля. Таким образом, обращение к методам неглобальных общих модулей выглядит как XXXXX.YYYYY, где XXXXX – это имя свойства общего модуля, а YYYYY – имя экспортируемого метода общего модуля.
Если установлено свойство Клиент (обычное приложение), то модуль загружается в толстом клиенте в режиме обычного приложения.
Если установлено свойство Клиент (управляемое приложение), то все процедуры и функции общего модуля могут использоваться в режиме Управляемое приложения, в тонком клиенте, в веб-клиенте.
Модули с установленным свойством Клиент (обычное приложение), проверяются для режимов запуска:
Модули с установленным свойством Клиент (управляемое приложение), проверяются для режимов запуска:
Модули общих объектов
Некоторые общие объекты имеют собственные модули. К таким объектам относятся:
Модули располагаются в ветках конфигурации, в которых содержатся сами объекты и являются свойствами объектов. Каждый объект имеет свой индивидуальный модуль. В этих модулях возможно объявление переменных, процедур и функций, которые будут доступны при работе с объектом извне во встроенном языке, дополняя контекст объекта.
Модули прикладных объектов
Набор прикладных объектов имеет собственные модули. К таким объектам относятся:
Модули располагаются в ветках конфигурации, в которых содержатся сами объекты и являются свойствами объектов. Каждый объект имеет свой индивидуальный модуль. В этих модулях возможно объявление переменных, процедур и функций, которые будут доступны при работе с объектом извне во встроенном языке, дополняя контекст объекта.
В контексте модуля прикладного объекта есть доступ к реквизитам и табличным частям объекта, а также его методам и событиям.
Модули менеджеров прикладных объектов
Каждый прикладной объект имеет менеджер, предназначенный для управления этим объектом, как объектом конфигурации. С помощью менеджера можно создавать объекты, работать с формами и макетами. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически, это позволяет описать методы для объекта конфигурации (например, справочника), которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации.
Контекст модуля менеджера образуется из:
Модуль менеджера не может иметь переменных и тела модуля.
Если функции или процедуры модуля менеджера объявлены как экспортируемые, к ним можно будет получить доступ через менеджер объекта.
Пример:
Модуль менеджера:
| Функция ПолучитьСписокДебиторов ( ) Экспорт … КонецФункции |
Вызов из прикладного кода:
Модули команд (модули общих команд)
Для нестандартных команд требуется написать процедуру ее выполнения. Для этого служит модуль команды, в котором можно написать предопределенную процедуру ОбработатьКоманду(). Данная процедура должна предваряться директивой компиляции &НаКлиенте, так как выполнение команды происходит в клиентском приложении.
Модули управляемых форм
Модуль состоит из набора процедур и функций. Переменные модуля и тело модуля не допускаются.
Модули форм
Эти модули содержатся в формах конфигурации. Каждая форма имеет свой индивидуальный модуль. В этих модулях возможно объявление переменных, процедур и функций, которые будут доступны при работе с формой извне во встроенном языке, дополняя контекст формы.
В контексте модуля формы доступны реквизиты формы, а также ее свойства, методы и события. Если у формы назначен основной реквизит, то в модуле формы становятся доступны свойства и методы прикладного объекта, используемого в качестве основного реквизита.