При создании новых прикладных решений на платформе «1С:Предприятие 8» разработчики часто сталкиваются с дилеммой: использовать проверенные временем обычные формы (ОФ) или переходить на технологически более сложные управляемые формы (УФ). Ситуация обостряется, когда заказчик планирует использовать систему исключительно в локальной сети или через терминальный доступ (RDP) силами небольшого количества пользователей (например, до 20 одновременных сеансов). На первый взгляд кажется, что классический «толстый клиент» на обычных формах решит задачу быстрее и дешевле. Давайте детально разберем эту проблему, проанализируем аргументы обеих сторон и выясним, почему выбор управляемых форм в современных реалиях является экономически и технически обоснованным.
Для начала проанализируем ситуацию с точки зрения жизненного цикла программных продуктов. Фирма «1С» официально прекратила активное развитие технологий обычного приложения. Все новые механизмы платформы, оптимизация производительности СУБД, механизмы защиты данных и интеграционные возможности разрабатываются исключительно под управляемое приложение. Оставаясь на обычных формах, мы добровольно соглашаемся на технологический тупик.
Рассмотрим ключевые архитектурные различия между ОФ и УФ:
Разберем экономическую составляющую проекта. Сторонники обычных форм часто аргументируют свою позицию тем, что при наличии терминального сервера (RDP) разницы в скорости работы и удобстве администрирования нет. Однако это порождает серьезные скрытые расходы для заказчика.
Проанализируем структуру затрат на организацию рабочих мест:
Существует миф, что на обычных формах писать код и проектировать интерфейс получается в разы быстрее. Давайте выясним причину этого заблуждения. Разработчики, привыкшие к ОФ, просто не освоили в достаточной степени декларативный метод проектирования УФ.
Посмотрим на практические аспекты верстки интерфейса:
В обычных формах разработчик вынужден вручную расставлять элементы управления на форме и настраивать так называемые «привязки» (границы элементов относительно краев формы). Это превращается в ад при необходимости динамически скрывать или показывать элементы в зависимости от прав доступа или условий. Форма часто «плывет» при изменении разрешения экрана пользователем.
В управляемых формах верстка является декларативной. Мы группируем элементы в вертикальные и горизонтальные группы, а платформа сама рассчитывает их положение и размеры на экране в зависимости от разрешения монитора и масштаба интерфейса. Это позволяет создавать адаптивные интерфейсы в разы быстрее.
Рассмотрим пример кода для работы с временным хранилищем в управляемом приложении. При передаче файлов или тяжелых структур данных с клиента на сервер мы должны использовать метод ПоместитьВоВременноеХранилище(). Это гарантирует, что данные будут сохранены в сеансовом кэше на сервере и не перегрузят клиентскую память:
&НаКлиенте
Процедура ЗагрузитьИОбработатьФайл()
АдресФайлаВоВременномХранилище = "";
ИмяВыбранногоФайла = "";
// Интерактивный выбор файла пользователем на клиенте
Если СделайВыборФайла(ИмяВыбранногоФайла) Тогда
// Помещаем файл в хранилище, привязывая его к УникальномуИдентификатору формы
АдресФайлаВоВременномХранилище = ПоместитьВоВременноеХранилище(Новый ДвоичныеДанные(ИмяВыбранногоФайла), УникальныйИдентификатор);
// Передаем управление на сервер для тяжелой обработки данных
ОбработатьФайлНаСервере(АдресФайлаВоВременномХранилище);
КонецЕсли;
КонецПроцедуры
&НаСервере
Процедура ОбработатьФайлНаСервере(Знач АдресХранилища)
// Получаем двоичные данные файла из сеансового кэша на сервере
ДанныеДляОбработки = ПолучитьИзВременногоХранилища(АдресХранилища);
// Реализуем серверную логику обработки (парсинг, запись в ИБ)
// ...
КонецПроцедуры
Этот подход разделения контекста на &НаКлиенте и &НаСервере требует от разработчика понимания клиент-серверного взаимодействия, но взамен обеспечивает колоссальную стабильность работы приложения.
Проанализируем, какие преимущества получают конечные пользователи системы при переходе на управляемые формы. Очень часто бизнес-пользователи требуют от программистов бесконечных доработок отчетов и списков документов: «добавьте колонку», «сделайте отбор по этому реквизиту», «раскрасьте строки». В управляемом приложении большинство этих задач решается силами самих пользователей без привлечения программиста.
Рассмотрим ключевые элементы интерфейса УФ:
ДинамическийСписок в управляемых формах работает на базе механизма компоновки данных (СКД). Он позволяет пользователю в режиме «Предприятие» самостоятельно настраивать группировки, добавлять любые отборы, настраивать условное оформление (например, выделять просроченные платежи красным цветом) и выводить реквизиты связанных справочников через точку. В обычных формах для этого приходилось писать сложный код в обработчиках событий ПриВыводеСтроки() или ПриПолученииДанных(), что сильно снижало производительность списков при прокрутке.Рассмотрим редкие исключения, когда разработка на обычных формах может быть оправдана:
Подводя итог нашему анализу, мы настоятельно рекомендуем разрабатывать любые новые конфигурации «с нуля» исключительно на управляемых формах. Использование обычных форм в новых проектах — это технологическое вредительство, которое лишает систему масштабируемости, увеличивает стоимость владения IT-инфраструктурой за счет лицензий RDP и усложняет дальнейшее развитие программного продукта.
Для успешного старта проекта на УФ рекомендуем использовать Библиотеку стандартных подсистем (БСП). Она содержит готовые блоки для работы с правами доступа, пользователями, историями изменений, печатными формами и обменами данными. Это позволит вам сосредоточиться на бизнес-логике вашего прикладного решения, не тратя время на написание базовых механизмов с нуля.