Совместное использование типов между службами WCF и их клиентами .net

Question

Совместное использование типов службами WCF и их клиентами .net

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

Мне нужно было сделать это, потому что у меня есть контракт на передачу данных, который будет использоваться в двух разных сервисах.Когда обе эти службы ссылаются на одного и того же клиента, это приведет к тому, что один и тот же тип данных будет доступен в двух разных пространствах имен.Для меня это выглядело так, как будто это создаст проблему неопределенности при использовании клиентом, или, по крайней мере, выглядит излишним.Кроме того, если я делюсь такими типами, разве это не противоречит цели предоставления услуги?

Что вы думаете об обмене типами между службой и клиентом, как это?Похоже ли это на плохой дизайн, который позже приведет к некоторым непредвиденным проблемам?... или просто необычный дизайн в целом!

Answer 1

Service / DataContract - это именно то, что говорит само слово: контракты. Весь смысл в том, чтобы поделиться им - в этом нет ничего плохого, и вы должны рассматривать типы как часть одного и того же Контракта (вы можете просто поделиться интерфейсами с вашими типами, если хотите).

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

Answer 2

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

Подход mex / wsdl особенно полезен при представлении общедоступного сервисного интерфейса или там, где кросс-платформенная переносимость является проблемой. Но если вам это не нужно, может быть очень заманчиво (правильно или неправильно) повторно использовать типы. Чрезмерно упрощенная версия этого может даже быть, когда приложение взаимодействует с тем же приложением на другом узле через некоторый частный API - введение отдельной модели типов здесь добавляет немного. Кроме того, совместное использование типов может дать более типичный API (с меньшими затратами кода), а с помощью логики в типах для выполнения проверки вы можете получить более полную проверку.

Я бы подошел к этому подробнее из того, «что мне нужно / ожидать» от этого сервиса; если «оно должно быть кроссплатформенным и не зависеть от модели типа в моем основном приложении», то его нет в списке, возможно, пересечь этот мост, если / когда оно возникнет.

Answer 3

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

Answer 4

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