Сколько ServiceContracts может иметь службу WCF?
В частности, поскольку ServiceContract является атрибутом интерфейса, сколько интерфейсов я могу кодировать в один веб-сервис WCF? Это один-к-одному?
Имеет ли смысл разделять контракты на несколько веб-сервисов?
У вас может быть сервис, реализующий все контракты на обслуживание, которые вы хотите. Я имею в виду, я не знаю, есть ли предел, но я не думаю, что есть.
Это аккуратный способ разделения операций, которые будут реализованы одной и той же услугой на нескольких концептуально различных интерфейсах контракта на обслуживание.
Услуги WCF могут иметь несколько конечных точек, каждый из которых может реализовать другой контракт на обслуживание.
Например, вы могли бы объявить следующую службу:
[ServiceBehavior(Namespace = "DemoService")]
public class DemoService : IDemoService, IDoNothingService
Которая имела бы конфигурацию в этих строках:
<service name="DemoService" behaviorConfiguration="Debugging">
<host>
<baseAddresses>
<add baseAddress = "http://localhost/DemoService.svc" />
</baseAddresses>
</host>
<endpoint
address =""
binding="customBinding"
bindingConfiguration="InsecureCustom"
bindingNamespace="http://schemas.com/Demo" contract="IDemoService"/>
<endpoint
address =""
binding="customBinding"
bindingConfiguration="InsecureCustom"
bindingNamespace="http://schemas.com/Demo" contract="IDoNothingService"/>
</service>
Надеюсь, что это поможет, но если вы были после теоретических максимальных интерфейсов, которые вы можете получить для службы, я подозреваю, что это немного безумно большое кратное 2.
@jdiaz
Конечно, вы должны стремиться к разным деловым вопросам в разных службах, но рассмотрите случай, когда вы хотите, чтобы, например, все ваши службы выполняли операцию GetVersion(). У вас может быть контракт на обслуживание только для этой операции, и каждая служба реализует его, а не добавляет операцию GetVersion() к контракту всех ваших услуг.
Теоретически у службы может быть любое количество конечных точек, и каждая конечная точка привязана к конкретному контракту или интерфейсу, поэтому для одной концептуальной (и настроенной) службы можно разместить несколько интерфейсов через несколько конечных точек или, альтернативно, для нескольких конечные точки для размещения одного и того же интерфейса.
Если вы используете класс ServiceHost для размещения своей службы, однако вместо IIS вы можете связывать только один интерфейс на ServiceHost. Я не уверен, почему это так, но это так.