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

И снова здравствуйте, дамы и господа!

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

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

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

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

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

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

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

Ответов (4)

Решение

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

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

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

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

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

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

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

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

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

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