и кузница и здравница и житница

а если реально смотреть на вещи - сложные печатные формы на скд - это КРАЙНЕ на любителя... можно в расчетный листок заглянуть

простые формы впрочем имхо тоже... овчина выделки не стоит

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

потому что вся "политика" самого фреймворка такая

есть абстрактный класс "документ". от него вы можете наследовать конкретный изолированный класс "накладная" и реализовать (в случае необходимости) объявленные в родительском классе методы. какие-то сервисные объекты (классы) не несущие на себе следы заточенности его под определенный бизнес-процесс сразу по сути объявлены изолированными. и крутись как хошь.

что делать когда найден "удачный" сервисный объект (класс) СКД? и хочется воспользоваться его возможностями и тут и там... он же не только для отчетов. на нем строятся списки, на нем строится много где основной gui в разных обработках - визуальные возможности СКД позволяют реализовать выбор каких-то сущностей с широкой вариативностью фильтров, сортировками и прочим. Т.е. позволяет не рисовать это все руками. Что сделал бы архитектор курильщика? Вероятно разбил бы объект на набор классов - чтобы можно пользовать то что необходимо конкретно здесь. Что делает архитектор здорового человека? Добавляет в объект костыль и объявляет что работать он будет только в списке, а этот костыль только для отчетов и т.д. Что в итоге видит разработчик? Какое-то адское месиво. Швейцарский нож из преисподней.

не улавливаю связи. от слова совсем

колхоз напрасный труд. "здесь мерилом работы считают усталость"

что "написано"?

вы не понимаете, что работа с коллекциями в 1С - из которой и состоит 90% внутренней бизнес-логики - это подходы 10-летней давности? и вендор не делает ничего чтобы упростить/улучшить этот аспект работы для разработчика?

в чем критика?

надо страдать как на Go? это не критика, это какая-то лажа. в стиле "дедушка служил и ты послужи"

авторДа в 1С если хочешь что бы все летало, надо кодировать, не хочешь что бы быстро - пиши одной строчкой кода.

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

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

какие скорости в 1С? там же интерпретатор. чем вы "управлять" собрались?

я понимаю когда пишут "нам нужна скорость".

и выносят часть логики во внешние компоненты, пишут прямые запросы через ADO

да на этом можно выиграть, даже с учетом сериализации данных туда/обратно

а вы какую "скорость" имеете ввиду?

нам дали "почти тру select" и теперь мы не лопатим из базы всё подряд? вау! хотя... я это еще в бэте 8.0 видел когда привез домой диск в 2002-ом с митинского радиорынка.

сейчас на минуточку 2019-ый. а вы всё о том же талдычите...