КД 3.1 - есть ли смысл плакать, но продолжать кушать кактус?
Последний раз работал с 3.0, когда нужно было обмен через ED делать, там выбора не было. А сейчас выбор есть - либо кд2.1, либо кд3.1. Функционал идентичен, вроде даже взаимозаменяем (протокол один, но это неточно).
Время идет, решил обучиться новой программе - КД 3.1. Пока что ничего хорошего, удобного не нашел. КД 2.1 написан либо богами, либо разработчиками типовых конфигураций, который на ней же писали все типовые правила обменов. КД 3.1, по ощущениям, написана "лишь бы было".
1. Ради чего стоит изучать работу в кд3.1?
2. Что поддерживает кд 3.1, чего нет в кд 2.1, если писать правила обмена в формате XML?
Время идет, решил обучиться новой программе - КД 3.1. Пока что ничего хорошего, удобного не нашел. КД 2.1 написан либо богами, либо разработчиками типовых конфигураций, который на ней же писали все типовые правила обменов. КД 3.1, по ощущениям, написана "лишь бы было".
1. Ради чего стоит изучать работу в кд3.1?
2. Что поддерживает кд 3.1, чего нет в кд 2.1, если писать правила обмена в формате XML?
Найденные решения
Когда КД3 появился то на курсах говорили что КД2.1 - для сложных случаев, гибкий, универсальный, но сложный. КД3 - для простых обменов.
Из плюсов КД3 называли отсутствие необходимости менять правила в одной из баз при обновлении другой базы, т.к. в отличие от КД2 в файле правил не зашиты версия релизов баз.
Из плюсов КД3 называли отсутствие необходимости менять правила в одной из баз при обновлении другой базы, т.к. в отличие от КД2 в файле правил не зашиты версия релизов баз.
Остальные ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
1. Разрабы используют КД 3.0 на совсем для того, для чего создавалось, т.к. по мысли ED - для универсального обмена, когда источник выкидывает все что есть в обмен, а приемник читает все, что нужно в универсальном обмене.
По факту обмен идет между заранее известными источниками и приемниками. Победили разве что проблему с разными версиями конфиг, когда обмен привязывался к конкретным реквизитам объектов, а они менялись.
По факту, обмен через ED переписывает объекты, даже если не просят (возможно косяк разрабов, но что есть), что явно не ускоряет обмен. НУ и кучу шлака универсально тащит, например в виде доп.свойств и реквизитов.
По факту обмен идет между заранее известными источниками и приемниками. Победили разве что проблему с разными версиями конфиг, когда обмен привязывался к конкретным реквизитам объектов, а они менялись.
По факту, обмен через ED переписывает объекты, даже если не просят (возможно косяк разрабов, но что есть), что явно не ускоряет обмен. НУ и кучу шлака универсально тащит, например в виде доп.свойств и реквизитов.
Когда КД3 появился то на курсах говорили что КД2.1 - для сложных случаев, гибкий, универсальный, но сложный. КД3 - для простых обменов.
Из плюсов КД3 называли отсутствие необходимости менять правила в одной из баз при обновлении другой базы, т.к. в отличие от КД2 в файле правил не зашиты версия релизов баз.
Из плюсов КД3 называли отсутствие необходимости менять правила в одной из баз при обновлении другой базы, т.к. в отличие от КД2 в файле правил не зашиты версия релизов баз.
Вакансии
1С-Программист (интегратор Битрикс24)
Санкт-Петербург
зарплата от 150 000 руб. до 250 000 руб.
Полный день
Санкт-Петербург
зарплата от 150 000 руб. до 250 000 руб.
Полный день