WCF: Как мне поддерживать классы контрактов на клиенте и сервере?

Question

Я работаю над приложением WCF с сервером и клиентом (естественно). В проекте сервера я определил классы с атрибутами contract .

Теперь, когда сервер готов, я добавил сервисную ссылку, и он создал прокси для меня. Я использовал его, и он работал нормально.

Вопрос, который я хочу задать, - это нормально, если я создам общую DLL, которая содержит определения классов с атрибутами контракта, и использую ее как для сервера, так и для клиента (вместо использования классов, сгенерированных для клиента Visual Studio). Если я использую общие классы, мне не нужно беспокоиться о том, чтобы при генерировании кода коллекции дженериков конвертировались в массивы. Это глупо? Является ли это возможным? Кто-нибудь делал это раньше? Можно ли это делать?

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

Answer 1

Если ваша единственная задача - не превращать коллекции в массивы, вам не нужно заходить так далеко. Кнопка «Дополнительно» в диалоговом окне «Добавить ссылку на службу» позволяет указать, какой тип использовать в таких случаях. Вы можете использовать его вместо T [].

Answer 2

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

Имеет смысл использовать общие типы , даже если вы не управляете всеми клиентами . Предположим, у вас есть служба, которая используется внутренними приложениями, использующими .NET, а также доверенными третьими лицами в компании-партнере. Партнерские приложения используют Java, Ruby или Python. В этом случае партнер не будет иметь доступа к общим типам, но, опираясь на WSD / XSD, может свернуть свою собственную библиотеку типов на стороне клиента. Это не должно мешать вам предоставлять хороший пакет общих типов для ваших собственных разработчиков.

Эта рекомендация для обмена типами также применяется при использовании интерфейса REST, а не WS / SOAP. При использовании REST WSDL отсутствует, но XSD (или аналогичный) по-прежнему будет использоваться для описания типов сообщений, которыми обмениваются сервер и его клиенты. Так что никаких изменений в советах, независимо от того, используете ли вы SOAP или REST.

РЕДАКТИРОВАТЬ: И это применяется независимо от того, используете ли вы .NET или Java или что-нибудь еще. Если вы контролируете оба конца провода и платформы одинаковы, тогда да, вы должны поделиться типами. Почему бы тебе?

Answer 3

Этот подход хорош (я использую это совсем немного) , пока вы управляете клиентом. Он не будет работать (очевидно) с java-клиентами и т. Д. Если вы знаете, что вам никогда не понадобится поддерживать не-.NET-клиентов, то он может быть мощным, но он нарушает некоторые чистые правила SOA. В частности, да, сценарий интрасети - это тот случай, когда я мог бы рассмотреть этот подход.

Как svcutil.exe, так и IDE имеют опции для повторного использования типов из существующих сборок, чтобы сделать именно это.

edit еще одно преимущество этого подхода - если вы хотите использовать ту же логику проверки на клиенте, не кодируя ее дважды - например, IDataErrorInfo и т. Д.

Answer 4

После того как вы создали отдельные сборки для хранения контрактов, вы можете ссылаться на эти сборки и использовать их для создания каналов (используя ChannelFactory ) для сервиса от клиента. При этом вам больше не нужно обновлять «сервисную ссылку» каждый раз, когда вы меняете сервисный контракт.

ChannelFactory<IContract> factory = 
    new ChannelFactory<IContract>("endpointName");