Навеяно темой Обычные формы против управляемых

Брукс в своём легендарном "мифический человеко-месяц" ещё в первой главе писал:

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

Потом нужно чтобы система работала в разных средах, имела интерфейсы с системами (с EDT, а, а, а?), чтобы это сделать опять нужно умножить на три, т.е. N *9 получается.


Почему КД 3 в состоянии "проги написали и работает"? Вот тут загрузка из файлов, а чтобы загрузить из файла пойди туда и догадайся, описания норм нет и вообще тыжпрограммист

КД2 работает отлично

(1) Я знаю. Но КД3 удобнее и круче (в теоретической части). Вся сериализация и XML в модулях спрятанных от "программиста-пользователя" а вся логика вот в одном месте - под отладчиком. Помните как классно отлаживать КД2? А тут вот всё хорошо придумано. Почему инструмент такой уродский?

(2) Я не помню, не использовал. А интерфейс КД3 уродский в угоду уродам без чувства прекрасного. Давайте их как-нибудь назовём: гоблины?

(0) КД3 изначально слишком оптимистично-идеалистичная идея

(4) Ну ок...

(4)
КД3 была нужна, чтобы не запускать на выполнение в 1С-фреш программный код, полученный из файла.
Это реализовано.

(0) КД3 по сравнению с КД2 выглядит как жалкая поделка к сожалению. Такое ощущение что КД3 была написана дилетантами.

(7) Два раза КУ Большому 1С. КД3 получился чтобы в конвертацию не лезли случайные люди, которые реализуют круговой обмет данными 🤦

А для для локальных задач пользуюсь Универсальными инструментами и своей допиской КД2 - https://infostart.ru/1c/tools/1176839/
Универсальный обмен данными в формате XML (с фильтрами и прямой загрузкой через HTTP сервис

КД3 хороша именно для обмена с типовыми конфигурациями, особенно если туда надо что-то грузить, т.к. при этом конфигурация-приемник в подавляющем большинстве случаев вообще не требует доработки

КД2 наше всё!

Сорри за некропостинг. КД3 хороша для обмена типовыми конфигурациями потому что хреново реализована идея типизирования данными обмена. Ведь можно написать свой формат  обмена под свои любимые конфигурации, зафиксировать его, в этом случае КД3 выступает даже некоторым инструментом документирования соглашений об обмене.
Просто задокументировано всё через жопу, а скорее никак, поэтому это кажется сложным и ненужным. Если бы КД3 как конфигурация была написана по-человечески, про КД2 уже бы забыли.

(11) КД2 может обмениваться не только с 1С-ными продуктами.
КД3 только с конфами на БСП.

(0) Я вообще не понимаю зачем КД3 есть. Ни разу не столкнулся с ситуацией, с которой КД2 не справилась бы. Кто-то может мне объяснить в чем фишка КД3? Правда, скажу честно, я ее только мельком видел и не изучал, но отзывов нелицеприятных про нее много прочитал.

(13) затем, чтобы делать обмен не по правилам XML, а через т.н. универсальный формат.

у которого есть свои достоинства (возможность передачи в гетерогенной среде).

(14) а теперь объясни, что такое гетерогенные среды? И чем формат XML не так универсален, как непонятный "универсальный формат". XML я представляю как сериализовать, а что такое "универсальный формат"?

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

(15) XML это только транспорт.
КД2 предполагает существование двух баз - источника и приёмника, каждая со своей конфигурацией. Если этих баз больше двух, количество правил растёт как N! (как написано в (15)). Кроме того, необходимо отслеживать обновление всех баз и корректировать правила.
КД3 использует некую виртуальную, не существующую фактически, конфигурацию, структура которой описана в Enterprise Data. И все прикладные конфигурации обмениваются в этом формате. Количество необходимых правил резко снижается. Кроме того, формат Enterprise Data стабилен и не скачет от обновления к обновлению.
КД2 гораздо нагляднее и проще в освоении, ИМХО.

(13)  КД3 была написана с одной целью - удешевить разработку обменов между типовыми конфигурациями для фирмы 1с. Она сделана не для удобства разработчиков, а только с целью уменьшения затрат 1с, создание единого обмена формата для типовых конф. (БП,УТ, ЕРП, КА, УХ).

В плане применения КД3 в других целях, например для своих нетиповых обменов, выгрузки остатков , переноса данных между различными системами она совершенно не подходит. Это все равно что забивать микроскопом гвозди. КД2 в разы функциональней, лучше и универсальней.

Странно что КД3 именует себя "универсальным форматом", хотя на самом деле никакой универсальности в ней нет от слова совсем.

(18) ...хотя на самом деле никакой универсальности в ней нет ...
Чтобы написать правила в КД2 нужно получить структуры метаданных источника и приёмника. А для этого они должны там быть. Т.е. источник и приёмник - это только конфигурации 1С.
Формат Enterprise Data описан в виде XDTO. Бери его оттуда в условный "Парус" - и в перёд и с песнями, обменивайся. Хоть с 1С хоть между "Парусами". Хотя последнее, конечно, фантастика :-)

(19) Вы видно владете только поверхностыми теоретическими знаниями по обменам. Практики я думаю практический нет.

С помощью КД 2 может обмениваться и не с конфигурациями 1с, никто не мешает разбирать XML в асболютно любой системе. Другое дело , что ее основное назначение это обмен между системами на 1с.

(17) Это тоже голая теория.

На практике если есть зоопарк систем из 10-20, там далеко не все конфигурации будут свежими на БСП. Может даже что то на 7.7 будет, какие то конфы нетиповые на 1с 8, где тоже не будет БСП и соотвественно поддержки КД 3 не будет.
при множестве систем КД как раз повзолит обмены сделать быстро , дешево и надежно, а КД 3 нет.

но при таком зоопарке систем как правило уже используют шины данных

(20) >>но при таком зоопарке систем как правило уже используют шины данных
шина это только транспорт, в нее может "писать и слушать" хоть обмен на кд2 хоть на кд3 хоть самописка с json...

(22) Вот именно.

Допустим в шину нужно выгрузить только пару определённых полей, из 5 справочников. в КД 2 это делается на раз два. чем прикручивать к конфе универсальный формат в котором во первых избыточна информация в формате, во вторых нужной в 95% нужной информации нет и его надо допиливать, в третьих сама система если не типовая или старая на 1с8 ,8.1, 8.2 или 7.7 и не подердживает унивресальный формат (тогда придется менять конфигурацию, только зачем нужен этот гемморой ?).

но еще легче сделать бывает чисто на JSON,

(22) КД3 делали не для нетленок (и тем более не для 7.7 делали), а для фреша.
Собственно вы же сами в (18) ответили - зачем дальше флуд разводить;)

P.S.
>КД2 в разы функциональней, лучше и универсальней.
С "лучше" я конечно я не соглашусь - потому что "лучше" это слишком относительное понятие.
Например, даже по задумке КД2 это просто шедевр быдлокодерства и заплатничества. Да, если нужно "здесь и сейчас" - инструмент отличный, а если требуется поддерживать обмен силами какого-то коллектива (а не одного левши, сделавшего первую версию за условные 4 часа) - инструмент как минимум очень спорный.

(23) сделал на КД3 свой обмен между базами бит.финанс, структура объектов полностью своя. Так что для использования в "нетленках" не вижу проблем.

Если знаешь КД2 и КД3, то скорость настройки обмена наверно сопоставима.

(0) Аналогичного мнения, сам уже несколько раз постил о неудобствах и проблемах.

(23) Да, и минус у КД2 очень существенный - его адски сложно отлаживать.
НО плюсов очень много..
В общем и тот и тот инструмент нужен, но для разных целей.

(26) Почему вдруг КД2 сложно отлаживать, код обработок выгрузки/загрузки открытый весь, отлаживай не хочу. В плане отладки особо разницы нет. И там и там есть внутренние механизмы, которые сложные и их сложно отлаживать и есть вставки своего кода, которые можно отладить довольно просто. Только что в КД2 этот код обернут в "Выполнить()", но не думаю что вытащить код из "Выполнить()" это прямо адская сложность.

В теории когда много систем КД3 имеет общий формат файла, поэтому нужно сделать меньше вариантов обменов. А на практике когда ты делаешь обмен на КД3 тебе всегда надо учитывать возможные влияния на другие интегрируемые системы. Вот сейчас делаю обмен на КД3, есть БП и к ней привязаны ЕРП, ЗП, УХ, скоро добавится еще обмен между ЕРП и ЗП, да есть еще битрикс. Это такая головная боль когда обмен один и приходится постоянно учитывать влияние всех систем сразу, лучше уж чтоб было много отдельных обменов, было бы в разы проще вносить изменения.

(27) Сложность отладки в том, что невозможно пошагово отлаживать обработчики, зашитые в правила. Точнее, теперь невозможно. Когда-то можно было. Но потом 1С эту лавочку прикрыла, из соображений безопасности.

КД 3 очень своеобразный инструмент для тех кому не в лом разрабатывать свои xdto-пакеты на каждый чих. Для крупных организаций с шинами данным и зоопарком конфигураций наверное полезна в иных случаях 2.0 приятнее

Вполне вероятно, что какой-то важный человек посередине разработки соскочил и работа банально пошла по звезде

(2) (26) Раньше можно было при отладке КД2 вставлять внешние обработки.
Сейчас нужно в правилах при выгрузке или загрузке обращаться к экспортной процедуре \ функции общего модуля и передавать туда нужные данные для отладки. Соответственно, эти процедуры \ функции можно добавить через расширение.

(28) Комментишь всего одну строку кода и получаешь старые возможности... :))) Даже на Инфостарте есть статья... :)))

(31) Соответственно в эти процедуры\функции вставляете обработчики, алгоритмы из правил, изменяете маленько и вперед с песней

(32) это смотря где, не везде взлетает таким способом

(34) А где не взлетает? Механизм везде типовой