My<cod/>.net
Большие, сложные объекты как результат работы веб-службы
Еще раз здравствуйте, дамы и господа!
OK, вслед за моим другим вопросом о результатах веб-службы ASP.NET, Прокси-классах и преобразовании типов . Я пришел к той части своего проекта, где мне нужно надеть свою мыслительную шапочку.
В принципе, у нас есть большой, сложный пользовательский объект, который должен быть возвращен из веб-службы и использован в клиентском приложении.
Теперь, основываясь на предыдущем обсуждении, мы знаем, что это будет затем принимать форму прокси-класса(классов) в качестве возвращаемого типа. Чтобы преодолеть это, нам нужно в основном скопировать свойства от одного к другому.
В данном случае, это то, что я бы очень, очень, очень хотел! хотелось бы избежать!
Так что, это заставило меня задуматься, как еще мы могли бы это сделать?
Мои текущие мысли заключаются в том, чтобы включить объект для полной сериализации в XML, а затем вернуть XML в виде строки из веб-службы. Затем мы десериализации на клиенте. Это будет означать изрядную часть украшения атрибутов, но, по крайней мере, код на обеих конечных точках будет легким, а именно, просто используя сериализатор .NET XML.
Что вы думаете по этому поводу?
Сериализация .Net XML (de) довольно хорошо реализована. На первый взгляд, я не думаю, что это вообще плохая идея.
Если два приложения импортируют одно и то же определение класса C#, то это относительно хороший способ получить поведение конструктора копирования бесплатно. Если структура класса изменится, то все будет работать, когда обе стороны получат новое определение класса, без необходимости вносить какие-либо дополнительные изменения на стороне потребления/построения веб-сервиса.
Есть небольшие накладные расходы на сборку и демарширование XML, но это, вероятно, затмевает накладные расходы на вызов удаленной веб-службы. .Net XML сериализация хорошо понятна большинству программистов и должна дать простое в обслуживании решение.
Я люблю JSON за такие вещи. Я только что закончил портал типа POC drop-things для моей компании, используя jQuery для связи с веб-службами с включенной службой сценариев. Сообщения, легкие и синтаксического анализа и т. д. довольно сильно обработаны. Материал jQuery ajax , который я читал, был здесь (люблю его!): jquery ajax статья
Вчера у меня было несколько отличных ответов на очень похожую тему, которые могут быть полезны для вас:
Связь между javascript и сервером
Роб, если посмотреть на ваш второй вопрос, а также на этот, то это звучит как точная ситуация, в которой мы находимся в нашем окружении. Однако мы перешли от ASP.Net веб-служб к WCF веб-службам и в процессе решили (по большей части) эту проблему.
Если есть хоть какой-то шанс, что ваш веб-сервис может быть реализован как веб-сервис WCF, это может сработать и для вас. Я должен отметить, что в то же время мы сохранили обратную совместимость с некоторыми клиентскими приложениями, которым требуется "стиль веб-службы ASP.Net" реализации, используя привязку WCF basichttp для транспорта службы. Конечным результатом является то, что наши клиентские приложения "newer" могут использовать наши реальные бизнес-объекты (посредством ссылки на assembly, содержащий только эти общие объекты) в качестве типов возврата из вызовов веб-службы, поскольку они делают фактические вызовы WCF.
Мы делаем это, не используя автоматически генерируемые прокси-классы и создавая свой собственный клиентский канал для связи с сервисом WCF.
Если вы можете использовать WCF, дайте мне знать, что я могу опубликовать дополнительную информацию.