МСУпробегалло, что-то ляпнул и нормально. Что ляпнул - не важно, главное, что ляпнул.

Тебе правильно сказали, что ты не держался даже за хвост, а умничаешь про хобот.
Какие еще xsd(web api работает с типизированными данными, а xml/json на выходе только за счет сериализаторов)? xslt только тебе уперлись, а широковещательной рассылки там никогда не было, тк это функционал signalr

МСУP.S. Основное достоинство XML это то, что есть возможность применить схемы XSD и декларативную трансформацию XSLT. JSON удобен только для небольших пачек данных от браузера к серверу и обратно. Для интеграции JSON курит в сторонке.

Можно и без web api.
1. xsd совершенно не нужны, более того, они вредны и дают значительные тормоза, если следовать рекомендациям ms и использовать serializator'ы для типизированных данных.
2. объем передачи данных xml превышает json в два раза, а используемой памяти в четыре. Поэтому те, кто в танке стараются избегать этой гадости.

AntonariySeVa xsd совершенно не нужныУ меня есть две задачи, в которых без xsd совершенно никак. Вернее в одной никак, а во второй очень-очень хреново без xsd.

1) Импорт разного хлама в БД. В специальную папочку забрасываются xml-файлы, сервис их подбирает, с помощью xsd определяет, что за фигню набросали, и выполняет соответствующие хранимые процедуры импорта.
2) Формальное описание языка разметки. Причем, подключив еще пару автогенеренных из EF-классов xsd, его можно расширить объектами текущей модели. Интеллисенс все это дело подхватывает и невозбранно подсказывает, что и где писать.

1. Если я правильно понял, то устраиваем общую свалку, далее методом перебора с помощью xsd пытаемся определить, что же там лежит. Как-то не очень вкусно пахнет.
2. xml что-то совсем не наблюдается, один xsd

МСУSeVa1. xsd совершенно не нужны, более того, они вредны и дают значительные тормоза
Ну, разве что, только в голове. И при наличии кривых рук. В остальных случаях сериализация и десериализация происходит на считанные доли секунд. У меня интеграционный XML файл более 10М десериализуется в класс порядка 3.5К кода за 0.3 секунды. Про какие значительные тормоза идет речь для меня загадка.

SeVa2. объем передачи данных xml превышает json в два раза, а используемой памяти в четыре. Поэтому те, кто в танке стараются избегать этой гадости.
Для сложных конструкций и нетривиальных структур обмена, наличие понятной схемы xsd (по которой можно и кодогенерацию прокси строить) на порядки важнее сэкономленных килобайт. Если танкисты это до сих пор не поняли, это их проблемы.

1. Для меня загадка - какое ты имеешь отношение к ИТ. 3.5К говнокода в одном классе - это сильно. У тебя большая, усидчивая задница.
2.Твои тупые партизаны в лесу еще не поняли, что одно дело это генерация прокси, а совсем другое - формат передачи данных, который может быть любой

МСУSeVa1. Для меня загадка - какое ты имеешь отношение к ИТ. 3.5К говнокода в одном классе - это сильно. У тебя большая, усидчивая задница.
2.Твои тупые партизаны в лесу еще не поняли, что одно дело это генерация прокси, а совсем другое - формат передачи данных, который может быть любой
1. Для меня загадка, твой кухарский опыт не выдерживает никакой критики. На лицо не только незнание и безопытность, а так же и полная деградация. В аттаче схема xsd от внешних поставщиков на 0.5К строк, очень замороченный и специфичный пакет xml для интеграции получается. Размер порядка 10-15М. По такому xsd получается *.cs класс на 3.5К кода, который я демонстрировал в предыдущих постах. JSON тут курит в сторонке в принципе, т.к. писать прокси класс руками - проще убить себя об стену.
2. А твои тупые извилины еще не поняли, что генерация прокси зависит от схемы, которую JSON не поддерживает? Писать классы на каждый чих и поддерживать их при модификации схемы обмена - ад. В случае кодогенерации я нажал перегенерировать класс и получил новую обменную версию, не заморачиваясь на том, что именно и как изменилось. Последующий ребилд класса покажет ошибки, если они есть. Я автоматом получаю класс и сосредоточен на прикладной задаче, а не на ковырянии в файлах.

Муслима, я наконец-то понял твой бред, ты как всегда не в ладах с терминологией и перепутала теплое с мягким. прокси-класс - это совсем другое.
Я очень рад твоему прогрессу, помнится, совсем недавно ты с умным видом "вещала", что xml парсить нужно
только вручную , и глупо хихикала относительно xsd.exe, тупо решив, что ее нужно запускать в самих wcf сервисах. В очередной раз продемонстрировала, что ничего не понимаешь в том, что тебе говорят.
Тогда ты подобным никогда не занималась, а когда довелось повстречаться даже с таким примитивом(ты еще не работала с внешними сервисами, где такого добра под несколько сотен классов), сразу о ней вспомнила.
Надеюсь, что через пару лет твоя всосешь, что xml/json - форматы передачи, есть сериализаторы, которые делают все на автомате, и в том и другом случае можно работать с типизированными классами. Именно так и происходит в web api.

Муслима, нагадила себе на голову и испортила воздух, а теперь пытается сделать вид,что это не она.
авторПо оценке трудозатрат. Ну 30 минут - это конечно байки бабушки, но:

1. Изучить структуру источника / приемника
2. Написать интеграционные классы, лучше сериализация-десериализация (никаких мля датасетов!)
3. Написать конвертер в xml
4. Тестирование (не тестеровщик)
5. Риски (умножаем сроки на 2)

Получаем смело рабочий день говнокодера. То есть ка-бы не загоняем в угол ни себя, не ущимляем заказчика.
В идеале нужна функциональная спецификация, в которой черным по белому будет расписана логика.

Dangreon
При наличии большого XML файла рискуете получить ошибку "OutOfMemoryExeption" (при использовании DataSet)

Транспортировать "многобукав" в xml - утопия, он для этого не предназначен.


День вместо пяти минут, зарабатываешь задницей,а не головой.