WCF: Почему контракт на конечной точке, а не на обслуживании?

Question

Попытка действительно "получить" контракты конечной точки:

Я понимаю, что предлагал разные конечные точки для поддержки разных привязок, но когда можно было бы определить n конечных точек для службы и использовать разные контракты? Кажется, что в большинстве случаев (за исключением IMetadataExchange) контракт с конечной точкой будет одинаковым независимо от протокола, нет?

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

Спасибо за помощь с небольшими вопросами, которые не дают мне спать;-)

Answer 1

Хорошо, хорошо - сервис, который вы определяете в <service> тег - это фактический код реализации - фактические строки C# или VB.NET, составляющие службу. Следовательно, это конкретный класс (который может даже реализовывать несколько сервисных контрактов). Это только на стороне сервера.

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

Это делает вещи немного яснее?