Цитата:
Сообщение от
DSPIC
Оккей, давай по существу. Как будешь решать задачу десериализации? У тебя на входе строка JSON.
Не нужно пытаться подменять одну задачу на другую в попытках доказать свою правоту
При разработке кастомного сервиса в D365FO нет задачи десериализации строки JSON на входе (хотя бы потому, что на входе может быть XML - если сервис будут дергать как SOAP). Нужно думать о том, чтобы разработать внятный контракт сервиса, а об остальном должны позаботиться платформа и клиент, вызывающий сервис. Если вы разработали контракт, в котором передается строка в JSON (ну мало ли - обстоятельства или контрагенты заставили), то это - совсем другая история. Я приводил штатный пример из FormLetterContract: на вход может подаваться строка, где в base64 закодирован бинарный контейнер, в который запакована коллекция записей произвольной таблицы. Ну и что это доказывает? Что все гланды на свете надо удалять через.. выхлопную трубу?
Платформа заботится о разработчике, беря на себя десериализацию и проверку корректности входного контракта сервиса - ей надо лишь чуть подсказать с помощью
правильных атрибутов, если на входе ожидаются объекты-коллекции. Вообще вся тема, как мне лично представляется, не про вопрос
выбора того или иного атрибута для поля-коллекции в контракте, не про то, что какие-то атрибуты кому-то
нравятся больше, а кому-то - меньше, что от одних исходит аромат высоких стандартов разработки, а от других - затхлый запашок предыдущей версии системы, которая уже и с поддержки снята, и AIF-а вашего в новой версии нет, и вообще... Тема, по-моему, про то, сколько проблем и ручного труда можно поиметь, если использовать
неправильный атрибут. Используйте правильный атрибут - и тратьте больше времени на бизнес-логику, а не на ковыряние в JSON-ах, парных квадратных скобках и форматах кодирования дат. Это всё уже давно решено в платформе, зачем изобретать велосипед?..
PS. С наступающим Новым годом
