Должен ли я привязываться напрямую к объектам, возвращаемым из веб-сервиса?

Question

Должен ли я привязываться напрямую к объектам, возвращаемым из веб-сервиса, или у меня должны быть объекты на стороне клиента, которые я привязываю к своим gridcontrols? Например, если у меня есть служба, которая возвращает объект Car, должен ли у меня быть объект Car на стороне клиента, который я заполняю значениями из объекта Car веб-службы? Что считается лучшей практикой? В C # мне нужно помечать свои классы как сериализуемые или делать что-то особенное для них?

Answer 1

Это хороший вопрос, который следует тем же строкам, что и два вопроса, которые я сам себе задавал:

1. Большие, сложные объекты как результат веб-службы .
2. Результаты веб-службы ASP.NET, классы прокси и преобразование типов .

Обе эти книги могут быть вам полезны.

Вот мои два бита:

• Старайтесь по возможности сохранять типы возврата ваших веб-сервисов примитивами. Это не только помогает уменьшить размер сообщений, но также уменьшает сложность на принимающей стороне.
• Если вам нужно вернуть сложные объекты, верните их в виде необработанной строки XML (я объясню ниже).

Затем я создаю отдельный класс, который представляет объект и обрабатывает его как XML. Я гарантирую, что класс может быть легко создан и сериализован в XML. Тогда оба проекта (веб-сервис и клиент) могут ссылаться на DLL с конкретным объектом, но нет раздражающей связи с прокси-классом. Эта связь вызывает проблемы, если у вас есть общий код.

Например (используя ваш Car класс):

• Метод веб-службы (CarFactory) BuyCar(string make, string model) - это фабричный метод, который возвращает автомобиль.
• Вы также пишете класс Mechanic, который работает с Car объектами для их восстановления, это разработано без ведома веб-службы.
• Затем вы выбираете класс Garage для своего приложения. Вы добавляете веб-ссылку на сервис CarFactory, чтобы получить свои машины, а затем добавляете некоторые Mechanic в свой гараж, а затем ломаете костяшки и готовитесь получить несколько машин с завода, чтобы заставить их работать.
• Затем все падает, когда вы получаете результат CarFactory.BuyCar("Audi", "R8") и затем говорите своему Mechanic.Inspect(myAudi) стону компилятора, потому что Car на самом деле имеет тип CarFactory.Car, а не оригинальный Car тип, да

Итак, используя предложенный мной метод:

• Создайте свой Car класс в своей собственной DLL. Добавьте методы для его создания и сериализации из / в XML соответственно.
• Создайте свой CarFactory веб-сервис, добавьте ссылку на DLL, постройте свои машины, как и раньше, но вместо возврата объекта верните XML .
• Создайте Garage, добавив ссылку на DLL-библиотеку Mechanic, Car и веб-службу CarFactory. Вызовите метод BuyCar, и теперь он возвращает строку, затем вы передаете эту строку классу Car, который перестраивает его объектную модель. Mechanic могут с радостью поработать и над этими Car's, потому что все поют из одного листа гимнов (или DLL?):)
• Одним из основных преимуществ является то, что если объект изменяется в своем дизайне, все, что вам нужно сделать, это обновить DLL, а веб-служба и клиентские приложения полностью отделятся от процесса.

Примечание: Часто бывает полезно создать второй слой Facade для работы с веб-сервисами и автоматически генерировать объекты из результатов XML.

Надеюсь, это имеет смысл, если нет, тогда, пожалуйста, кричите, и я уточню.

Answer 2

Если вы являетесь владельцем веб-службы и клиентом.
И вам нужно, чтобы параметры вызовов веб-службы были сложными классами, которые содержат не только данные, но и поведение (фактическую кодированную логику), тогда вы немного расстроены, когда разрабатываете эти веб-службы с использованием фреймов веб-службы.
Как предложено в ответе Роба Купера , вы можете использовать чистый xml в качестве параметров веб-службы и сериализации xml, но есть более чистое решение.
Если вы используете Visual Studio 2005 (вероятно, применяется то же самое для 2008 года), вы можете настроить способ, которым VS создает ваш прокси, как описано в этой статье: Настройка сгенерированных прокси веб-служб в Visual Studio 2005

Таким образом, вы можете указать VS использовать свои собственные классы вместо генерации прокси-класса.

Что ж, когда я об этом думаю, это почти то же самое решение , которое предложил Роб Купер, с небольшим поворотом, что вы сами не будете писать слой Фасад, но будете использовать сам VS как этот слой.

Answer 3

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

Answer 4

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

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

В долгосрочной перспективе зачастую лучше создавать конкретные объекты на стороне клиента, а затем преобразовывать их в типы контрактов данных веб-служб и из них. Это может показаться большой работой, но это часто окупается, когда пришло время проводить рефакторинг, так как ваши изменения локализованы в одном месте.

Answer 5

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

Ваши объекты и / или коллекции на клиенте отслеживают изменения? Если это так, вы можете использовать их.

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

Опять же, это действительно зависит от того, что вы получаете, что они поддерживают, что вы делаете с ними, а также от того, какой ответ сервер хочет вернуть за изменения.