Как работают управляемые формы и тонкий клиент 1С – взгляд «из-под капота»
Переход на управляемые формы перевернул процесс разработки на 1С, заставив программистов менять привычные подходы к описанию логики работы интерфейса. Руководитель компании «Цифровой Кот» Юрий Лазаренко в своем докладе на конференции Infostart Event 2019 Inception рассказал о том, как устроены управляемые формы и как правильно работать с тонким клиентом платформы 1С:Предприятие.
Добрый день, коллеги! Я – Юрий Лазаренко, инженер-программист с опытом разработки программного обеспечения 31 год. Из них 19 лет – в 1С. Я управляю компанией «Цифровой Кот», мы разрабатываем сайты на 1С. Причем не только разрабатываем, но и успешно продаем – так успешно, что среди наших клиентов есть даже такие названия, которые произносят обычно шепотом, с пиететом. В моем докладе 60 слайдов, и у меня всего лишь 30 минут. Поэтому сейчас – краткое вступление и… погнали.
Вступление. Зачем писать свой веб-клиент, если есть веб-клиент 1С?
Мы действительно написали свой полноценный веб-клиент, который в какой-то мере является конкурентом веб-клиенту (тонкому клиенту) платформы 1С. На самом деле, не конкурентом, просто он в каких-то случаях отлично дополняет веб-клиент. Куда нам конкурировать с 1С? Мы не хотели его писать изначально – все из-за лени. Лет 10 назад мне понадобилось вывести кое-какую информацию из базы 1С на сайт, было лень учить PHP, и я написал небольшой модуль на 1С. Потом оказалось, что это можно продавать клиентам – они стали просить добавить это, то, другое, третье. В итоге, через 10 лет мы имеем то, что имеем. Наш веб-клиент практически на 100% повторяет функциональность тонкого и веб-клиента 1С. При этом у него есть как слабые, так и сильные стороны – даже некоторые преимущества. Самое важное замечание – все выводы, о которых я сегодня буду говорить, основаны на анализе работы нашего веб-клиента, а не веб-клиента 1С. То есть, некоторые выводы могут быть ошибочными, но вероятность этого крайне мала, потому что принцип функциональности нашего веб-клиента и веб-клиента 1С практически совпадает. 
К вопросу – зачем нужно было писать свой веб-клиент, если есть веб-клиент 1С? На слайде показан реально работающий кейс на примере обработки лидов в интерфейсе Битрикс 24. 
При клике на лид в окне Битрикс 24 с помощью нашего веб-клиента во фрейме отображается форма документа, которая соответствует этому лиду в 1С. В режиме онлайн выводим все данные, соответствующие этому лиду. 
Нажимаем кнопку «Записать и закрыть», и это все моментально попадает в 1С – без всяких обменов. Попробуйте это сделать каким-то другим способом, а мы так уже умеем. Это к вопросу о преимуществах.
Чем отличаются веб-клиент и толстый клиент
Чем принципиально отличаются толстый и тонкий клиент? Это цитата из Википедии. Толстый клиент максимум функциональности по обработке информации переносит на машину клиента. Тонкий клиент, наоборот, все делает на сервере. Казалось бы, при такой ситуации толстый клиент должен работать быстрее, потому что он не использует распределенную вычислительную сеть. Так оно и есть, вернее, так оно и было лет 10 назад, пока все работали за стационарными компьютерами. 
Сегодня клиент крайне разнообразен. Желающих зайти в 1С через смартфон и посмотреть информацию в режиме онлайн очень много. Это не только директора, которые, сидя на Бали, хотят смотреть отчеты и согласовывать какие-то там заявки. Это вполне рабочие люди – сервисные выездные инженеры, торговые представители. Это могут быть клиенты, которые хотят прямо на мобильном телефоне набрать какой-то заказ – мы выполняем подобные проекты. Поэтому интерес к веб-клиенту существенный, он растет, и на него нужно переходить. Но при этом, если вы попробуете на мобильном телефоне в толстом клиенте отобразить форму, например, «Реализации товаров и услуг» и произвести сложный расчет ее табличной части, у вас это, скорее всего, не получится. Не только из-за размеров экрана – просто возможностей процессора смартфона на это не хватит. А вот тонкий клиент здесь отлично справляется, и я вам расскажу, почему. 
Нам в этом помогут как обычно, Арнольд Шварцнеггер, Кайл Шварц из «Южного парка», Осел из «Шрека» и какой-то мужик из «Стартрека».
Как открывается форма в толстом и тонком клиенте?
Как в принципе работает толстый клиент? Очень абстрактно – есть устройство пользователя, и есть СУБД, из которой нужно показать данные. Между ними – посредник, сервер «1С:Предприятия» (условно мы его называем «dll»). 
Когда толстый клиент хочет получить форму какого-то объекта из СУБД, мы получаем данные в виде примитивных типов – там же строки, цифры, ложь, истина и т.д. Затем эти данные упаковываются в структуру, создается «чертеж» формы («чертеж» объекта), который передается клиенту, и уже на стороне клиента из «чертежа» создается объект, а также реквизиты, методы и элементы формы. Элементы формы привязываются к реквизитам объекта, и для них назначаются обработчики событий. 
В тонком клиенте – абсолютно то же самое, но между клиентом и сервером появляется веб-сервер. 
Вот они, различия. Между клиентом и сервером добавилось лишнее звено – веб-сервер. Он здесь специально отмечен красным, потому что его вызов действительно лишний. Вызов веб-сервера каждый раз – это очень затратный с точки зрения времени процесс. При каждом запросе HTTP-протокола нам нужно вызывать сервер – это долго. И очень важное замечание: объект на управляемой форме – это не тот объект, с которым мы привыкли работать на сервере (ДокументОбъект, СправочникОбъект) – это тип ДанныеФормыОбъект. По сути, это структура с некими своими методами. Это – важно, это нужно запомнить. 
Итак, вывод первый: толстый клиент при прочих равных быстрее тонкого за счет отсутствия лишнего звена – веб-сервера. 
Почему тогда он медленнее? Дело в том, что в толстом клиенте при открытии формы происходит создание и инициализация объекта. Теперь представьте – у нас есть объект. Это справочник или документ – не важно. У него есть 100 реквизитов. Мы хотим вывести его форму и показать на ней всего один реквизит, а остальные скрыть. Но даже если эта форма будет нужна только для просмотра, даже если нам никакие методы объекта вообще не нужны, если нужно просто открыть, показать и закрыть – все равно с сервера на клиент объект придет весь. Он полностью инициализируется зря – этого не требуется, но все это сделается. Для него создадутся все элементы – даже скрытые все равно будут созданы, проинициализированы. Для каждого будут однозначно определены обработчики событий (чем это плохо, я расскажу потом). Получается, будет сделано много лишней работы для того, чтобы показать всего лишь одну цифру. 
Давайте представим, что объект – это Кайл. Это мальчик, наименование – Кайл, возраст – 11. У него есть такие методы? Он ябеда, хвастун, нытик, кушает свои козявки и т.д. Какие шансы у Кайла попасть в топ своей дворовой тусовки? Никаких. 
Но у Кайла есть еще один классный метод – «ВынестиМяч()» (у него есть мяч). Те, кто родились в 80-е, знают, что это такое, когда во дворе у кого-то есть мяч. Какие у нас тогда были развлечения? Лазить по стройке, поджигать карбид, надувать лягушек и играть в мяч. Если у кого-то есть мяч, ты – король двора, ты везде желанный. Если кто-то из молодых не понял, в чем прикол мяча, представьте, что вы на даче у бабушки, у вас нет интернета, у вас нет телевизора, из библиотеки – только журнал «Здоровье». И тут у вашего соседа есть PlayStation. Представьте PlayStation вместо мяча, и вам станет понятно, почему Кайл всем так интересен. На самом деле, Кайл никому не интересен. Но Кайл – это объект, у него есть реквизит, который нам нужен – мяч. Представьте, что вы, как толстый клиент, подходите к СУБД (к дому, где живет Кайл) и кричите ему под балконом: «Кайл, вынеси мяч». Он выходит на балкон: «Сейчас у мамки отпрошусь». И через пять минут у вас есть мяч – нужный вам реквизит. И вдобавок к нему – 50 килограммов Кайла со всеми его методами – нытьем и т.д., которые вам вообще не нужны. Вот так работает толстый клиент. 
В толстом клиенте элементы тянутся на форму и создаются, инициализируются, и все это делается даже в том случае, если они не нужны. 
Ну и ладно, пусть создаются. Но дело в том, что многие реквизиты – это ссылки. А ссылка, на самом деле, это – объект. Если у какой-то программной сущности есть методы, то, скорее всего, это объект. И эти методы тоже нужно сначала проинициализировать. То есть, вместе с инициализацией одного большого объекта Кайла мы инициализируем еще кучу микрообъектиков. Это тоже лишние действия. 
А как работает тонкий клиент? Представьте, что вы пришли в СУБД, говорите: «Кайл, вынеси мяч». Вместо Кайла выходит его мама – веб-сервер, лишнее звено, говорит: «Ребятки, вы к Кайлу? А Кайла нет, он у бабушки на даче. Вы что, хотели мячик? Я знаю, где он лежит. Хотите, я вам его сейчас с балкона скину?». 
А что, так можно было? То есть, вы получаете то, что вам нужно. Да, лишний посредник есть, но вы получаете именно то, что вам нужно, безо всяких Кайлов. Это же сплошные профиты! 
Итак, вывод второй: толстый клиент работает медленнее за счет выполнения огромного количества лишней работы по созданию объектов, элементов и увеличения трафика. 
Но есть еще один страшный момент. Дело в том, что даже если элемент скрыт, но он пришел на клиента, то тут есть проблемы с безопасностью. Реальный кейс из моей практики – давным-давно, в 2002 году, когда мы работали еще на 7.7 (это тоже толстый клиент), у нас спросили: «Почему все сотрудники могут видеть зарплату директоров?» Представьте, что вам нужно передать с сервера на клиент форму справочника. Как она передается в толстом клиенте? На сервере получаются все данные, дальше мы смотрим: этому сотруднику не нужно показывать зарплату. Толстый клиент на сервере эти данные скрывает, устанавливая им «Видимость = Ложь». А потом эти данные, хоть и скрытые, приходят на клиент. Но Бармалеи их какими-то хитрыми способами могут увидеть – я лично видел, как они их достают. Как действует тонкий клиент? На тонком клиенте создается структура элементов формы. Далее на эти элементы накладываются ограничения ролей, функциональных опций, программно наложенные ограничения (например, «УстановитьВидимость(Ложь)» при создании на сервере). Далее на сервере все данные, на которые наложены ограничения, с формы удаляются, и на клиент приходит только то, что разрешено. Если зарплата не пришла на клиента, никакой Бармалей ее никогда не увидит. А это означает, что безопасность тонкого клиента значительно выше. 
Тонкий клиент при этом еще и дальнобойнее, ведь, чтобы получить данные к СУБД, мы обращаемся к посреднику – веб-серверу, который обычно доступен отовсюду, где есть интернет. А толстому клиенту, условно, нужен доступ к dll, которая находится в локальной сети. 
Соответственно, третий вывод – тонкий клиент перспективнее:
- он обеспечивает доступ откуда угодно, где есть интернет;
- и его безопасность выше.
Как выглядит контекст формы в браузере
Следующий раздел – как выглядит контекст формы в браузере.
На слайде показано, как он выглядит у нас, в нашем тонком клиенте.
Помните, что вы видите, когда в отладчике выбираете объект и открываете дерево его реквизитов? У нас все то же самое. По сути, это структура:
- у нас есть реквизит «Вид цен», это – ссылка, у нее есть представление, идентификатор;
- реквизит «Дата» имеет тип дата;
- «Запасы» – с типом массив (по сути, это ТЧ) и т.д.
Как получить такую структуру на клиенте?