Чем управляемое приложение отличается от обычного в 1С

Обычное и управляемое приложение — это два режима работы платформы 1С:Предприятие 8, которые различаются архитектурой, способом построения интерфейса и моделью взаимодействия клиента с сервером. Обычное приложение появилось в версии 8.0 и 8.1, управляемое — начиная с платформы 8.2. Сегодня обычный режим считается устаревшим, но он всё ещё встречается в старых конфигурациях, поэтому различия между режимами важно понимать и разработчикам, и администраторам.

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

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

Архитектура: где выполняется код

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

В управляемом приложении действует трёхзвенная модель: клиент отвечает только за отображение, вся работа с данными выполняется на сервере (или на стороне серверного контекста в файловом режиме). Код в модулях явно помечается директивами компиляции — &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, и платформа контролирует, откуда какие вызовы допустимы.

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

Интерфейс: нарисованный против описанного

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

Управляемая форма строится иначе: разработчик задаёт дерево элементов, группировку и привязку к данным, а платформа сама рассчитывает расположение и размеры. Это даёт адаптивность, но ограничивает свободу «пиксельной» вёрстки — разместить элемент произвольно нельзя, только через группы и настройки отображения.

Отличается и интерфейс приложения в целом. Обычное приложение использует классические меню и панели инструментов. Управляемое работает в интерфейсе «Такси» (или устаревшем интерфейсе версий 8.2) с панелями разделов, функций, избранным и историей работы, что заметно меняет навигацию для пользователей.

Клиенты и способы запуска

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

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

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

Сравнение режимов

Обычное приложение

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

Управляемое приложение

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

Модальность и асинхронность

В обычном приложении модальные окна — норма: методы вроде Вопрос(), Предупреждение() и ОткрытьФормуМодально() блокируют интерфейс до ответа пользователя, и код продолжает выполняться после закрытия окна.

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

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

Как перевести конфигурацию на управляемый режим

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

Типовой порядок действий выглядит так:

1. 1
   Сделайте копию базы и выполняйте все работы только на ней.
2. 2
   В свойствах конфигурации установите основной режим запуска «Управляемое приложение» и проверьте настройку использования модальности.
3. 3
   Запустите проверку конфигурации (Конфигурация — Проверка конфигурации) с флагами проверки управляемого приложения, тонкого и веб-клиента — получите список несовместимого кода.
4. 4
   Создайте управляемые формы для объектов, у которых есть только обычные.
5. 5
   Перенесите обращения к данным из клиентских процедур в серверные, замените модальные вызовы на асинхронные с оповещениями.
6. 6
   Протестируйте ключевые сценарии в тонком и веб-клиенте, затем планово переносите изменения в рабочую базу.

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

Как проверить результат и типичные ошибки

После перевода конфигурацию нужно проверить во всех целевых клиентах. Успешный запуск в толстом клиенте не гарантирует работу в тонком: часть функциональности (например, некоторые OLE/COM-вызовы и работа с файловой системой) доступна не везде и требует расширений или обходных решений.

Контрольные точки

Как проверить результат

Запуск в тонком клиенте

Норма

Приложение открывается, формы отображаются, документы проводятся

Тревожный признак

Ошибки компиляции модулей или пустые формы

Запуск в веб-клиенте

Норма

Работают основные сценарии без модальных окон

Тревожный признак

Сообщения о запрещённой модальности или неоткрывающиеся формы

Проверка конфигурации

Норма

Нет ошибок по флагам управляемого приложения и веб-клиента

Тревожный признак

Ошибки обращения к серверным методам из клиентского контекста

Частые ошибки при переходе однотипны и хорошо предсказуемы.

Что выбрать для нового проекта

Для любой новой разработки выбор однозначен — управляемое приложение. Обычный режим не развивается, не поддерживает современные клиенты и интерфейс «Такси», а новые механизмы платформы ориентированы именно на управляемые формы и расширения.

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

Частые вопросы

Можно ли запустить обычное приложение в веб-клиенте?

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

Что произойдёт, если просто поменять режим запуска в свойствах конфигурации?

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

Может ли одна конфигурация работать в обоих режимах?

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

Почему в управляемом приложении запрещены модальные окна?

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

Что означают директивы &НаКлиенте и &НаСервере?

Это указания платформе, где компилируется и выполняется процедура. Клиентские процедуры работают с интерфейсом, серверные — с данными. Из клиентской процедуры нельзя напрямую выполнить запрос или изменить объект базы: для этого вызывается серверная процедура.

Стоит ли переводить старую самописную конфигурацию на управляемый режим?

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