WCF DataContract

Question

Если я не держу Сервисный контракт, прокси и Сервис в отдельной сборке, Сервисные контракты и Прокси находятся в Сборке Клиента, а Сервис находится в Сервисной сборке.

Если я не храню контракт данных в отдельной сборке, где он должен находиться: на стороне клиента или на стороне обслуживания?

Могут ли контракты данных находиться в обеих сборках?

Answer 1

В типичном сервис-ориентированном сценарии у вас есть DataContract в вашей сервисной библиотеке на стороне сервера. Любой, кто будет вам звонить, будет добавлять клиентское прокси-соединение к вашему сервису и, следовательно, будет дублировать ваш DataContract.

Таким образом, в «нормальном» случае у вас есть «главный» DataContract на стороне сервера и отдельный класс в каждом клиентском прокси, который обращается к вашему сервису. Эти клиентские копии "идентичны по проводам", например, они сериализуются в один и тот же формат сообщения - и это действительно все, что есть между вашим клиентом и вашим сервером - сериализованное сообщение, отправляемое туда и обратно.

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

Я бы предложил следующие как минимум два проекта для каждого сервера:

• a библиотека классов , которая содержит контракты на обслуживание (интерфейсы IService), контракты на данные и, возможно, контракты на отказ
• a библиотека классов или автономный EXE (консольное приложение), который содержит фактическую реализацию службы (классы, реализующие интерфейсы службы)

Марк

Answer 2

Ответ - это зависит.

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

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

Вы также можете создавать версии своих договоров самостоятельно.

Но все зависит от вашего фактического применения.

Answer 3

Я бы настоятельно рекомендовал иметь отдельную сборку, содержащую ваши интерфейсы и контракты, на которые ссылаются как сторона клиента, так и сторона сервера.