Большие, сложные объекты как результат веб-сервиса [закрыто]

Question

Еще раз здравствуйте, дамы и джентльмены!

Хорошо, следуя моему другому вопросу о ASP.NET Результаты веб-службы, прокси-классы и преобразование типов.Я подошел к той части моего проекта, когда мне нужно хорошенько подумать.

По сути, у нас есть большой, сложный пользовательский объект, который необходимо вернуть из веб-службы и использовать в клиентском приложении.

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

В данном случае, это то, что я бы очень, очень хотел, в самом деле! хотелось бы избежать!

Итак, это заставило меня задуматься, как еще мы могли бы это сделать?

Мои текущие мысли состоят в том, чтобы включить объект для полной сериализации в XML, а затем вернуть XML в виде строки из веб-службы.Затем мы десериализуем на клиенте.Это будет означать изрядное оформление атрибутов, но, по крайней мере, код в обеих конечных точках будет легким, а именно, при простом использовании сериализатора .NET XML.

Что вы думаете по этому поводу?

Answer 1

Сериализация .Net XML (де) реализована довольно хорошо.На первый взгляд, я вовсе не думаю, что это плохая идея.

Если два приложения импортируют одни и те же определения классов C #, то это относительно хороший способ получить поведение конструктора копирования бесплатно.Если структура класса изменится, то все будет работать, когда обе стороны получат новое определение класса, без необходимости вносить какие-либо дополнительные изменения на стороне потребления / построения веб-сервиса.

Существуют небольшие накладные расходы на маршалинг и демаршализацию XML, но это, вероятно, незначительно по сравнению с накладными расходами на удаленный вызов веб-службы.Сериализация .Net XML хорошо понятна большинству программистов и должна обеспечить простое в обслуживании решение.

Answer 2

Я люблю JSON для такого рода вещей.Я только что закончил портал типа POC drop-things для своей компании, используя jQuery чтобы связаться с веб-службами с включенной службой сценариев.Сообщения имеют небольшой вес, и синтаксический анализ и т.д. В значительной степени обрабатывается.Тот Самый jQuery ajax то, что я прочитал, было здесь (мне это нравится!). : статья о jquery ajax

Answer 3

Вчера у меня было несколько отличных ответов на очень похожую тему, которые могли бы быть полезны для вас:

Связь между javascript и сервером

Answer 4

Роб, рассматривая твой другой вопрос, а также этот, я понимаю, что это похоже на точную ситуацию, сложившуюся в нашем окружении.Однако то, что мы сделали, это отошли от ASP.Веб-службы Net к веб-службам WCF и в процессе решили (по большей части) эту проблему.

Если есть хоть какой-то шанс, что ваш веб-сервис может быть реализован как веб-сервис WCF, это может сработать и для вас.Я должен упомянуть, что в то же время, мы поддерживаем обратную совместимость с клиентскими приложениями, которые нужны "ASP.Net веб-службы в стиле" реализации с помощью basichttp привязки WCF для службы транспорта.Конечным результатом является то, что наши "более новые" клиентские приложения могут использовать наши реальные бизнес-объекты (посредством ссылки на сборку, содержащую только эти общие объекты) в качестве возвращаемых типов из вызовов веб-службы, потому что они выполняют фактические вызовы WCF.

Мы делаем это, не используя автоматически сгенерированные прокси-классы, а создавая наш собственный клиентский канал для связи со службой WCF.

Если вы, возможно, можете использовать WCF, дайте мне знать, я могу опубликовать некоторую дополнительную информацию.