Конфиг для WCF с несколькими конечными точками - PullRequest
2 голосов
/ 26 апреля 2010

Я новичок в WCF и пытаюсь донести до меня некоторые идеи.

В основном у меня есть проект веб-приложения WCF со следующим в его файле web.config:

<system.serviceModel>
    <services>
        <service name="WcfService1.ServiceContract.IDirectorySearchService" behaviorConfiguration="defaultServiceBehavior"> 
            <endpoint name="restxml" address="xml" binding="webHttpBinding" contract="WcfService1.ServiceContract.IDirectorySearchServiceXml" behaviorConfiguration="xmlRestBehavior"/>
            <endpoint name="restjson" address="json" binding="webHttpBinding" contract="WcfService1.ServiceContract.IDirectorySearchServiceJson" behaviorConfiguration="jsonRestBehavior"/>
            <endpoint name="soap" address="soap" binding="basicHttpBinding" contract="WcfService1.ServiceContract.IDirectorySearchService"/>
            <endpoint name="mex" address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        </service>
    </services>
    <behaviors>
        <serviceBehaviors>
            <behavior name="defaultServiceBehavior"> 
                <serviceDebug includeExceptionDetailInFaults="true"/>
            </behavior>
        </serviceBehaviors>
        <endpointBehaviors>
            <behavior name="xmlRestBehavior">
                <webHttp/>
            </behavior>
            <behavior name="jsonRestBehavior">
                <enableWebScript/>
            </behavior>
        </endpointBehaviors>
    </behaviors>
</system.serviceModel>

Мои интерфейсы выглядят так:

[ServiceContract]
public interface IDirectorySearchServiceXml  
{
    [OperationContract]
    [WebGet(UriTemplate = "Search/")]
    SearchResults Search();
}

[ServiceContract]
public interface IDirectorySearchServiceJson  
{ 
    [OperationContract]
    [WebGet(UriTemplate = "Search/")]
    SearchResults Search();
}

[ServiceContract]
public interface IDirectorySearchService
{
    [OperationContract]
    SearchResults Search(int? sportId, int? instituteId, DateTime? startDate, DateTime? endDate);
}

Теперь часть, с которой у меня возникли небольшие проблемы, - это то, что мне еще нужно, чтобы это запустить и запустить ... Например, учитывая, что .svc-файлы мне нужны, и у меня правильная конфигурация ... И какие адреса мне нужно использовать, чтобы запустить его через браузер или тестовый клиент WCF. Обратите внимание, я в настоящее время использую 3,5.

Приветствие Anthony

UPDATE:

Так что, если у меня что-то вроде следующего, мне понадобятся 3 разных файла SVC ... Если это так, то нет смысла иметь адресную часть в конечной точке ...

public class DirectorySearchServiceXml : IDirectorySearchServiceXml  
{
    ...
}

public class DirectorySearchServiceJson : IDirectorySearchServiceJson  
{ 
    ...
}

public class DirectorySearchService : IDirectorySearchService
{
    ...
}

Но я мог бы создать 1 класс, который явно влияет на все 3 интерфейса, тогда у меня был бы только 1 svc, и тогда адрес стал бы подходящим ... Это правильно?

Ответы [ 3 ]

2 голосов
/ 26 апреля 2010

Зависит от: -)

Если вы хотите разместить свои службы WCF в IIS (см. MSDN Как: разместить службу WCF в IIS ), как я предполагаю из вашего вопроса, тогда вам потребуются три вещи:

  • виртуальный каталог (и, возможно, его подкаталог), в который вы поместите файл службы (yourservice.svc) в
  • служебный файл - короткий однострочный
  • соответствующий раздел конфигурации в вашем web.config

Сервисный файл (* .svc) представляет собой крошечный однострочный текстовый файл, который дает IIS инструкции по созданию вашей службы. Это выглядит так:

<%@ServiceHost language=c# Debug="true" 
               Service="Microsoft.ServiceModel.Samples.CalculatorService"%>

Атрибут language определяет язык службы WCF, debug включает отладку (для dev и test, отключает ее для производства), а Service= определяет, какой класс (полностью квалифицированный с пространством имен и всем) на самом деле реализует ваши услуги.

Далее, вам нужно либо поместить эти реализации сервиса в файл с выделенным кодом * .svc (не рекомендуется), либо - намного лучше - скомпилировать реализацию сервиса WCF в библиотеку классов и вставить эту библиотеку классов в .\bin каталог под вашим виртуальным каталогом.

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

Ваши сервисные адреса будут определены

  • Сервер
  • виртуальный каталог (и возможные подкаталоги)
  • сам файл сервиса

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

Так что в вашем случае у вас будет

  • http://yourserver:port/YourVirtualDirectory/YourService.svc/restxml
  • http://yourserver:port/YourVirtualDirectory/YourService.svc/restjson
  • http://yourserver:port/YourVirtualDirectory/YourService.svc/soap

для ваших реальных функций и * http://yourserver:port/YourVirtualDirectory/YourService.svc/mex для обмена метаданными (который вы не будете использовать напрямую).

1 голос
/ 25 апреля 2012

У меня также были некоторые проблемы с несколькими конечными точками в одном сервисе.Я всегда получал ошибку 400. Моя ошибка не состояла в том, чтобы использовать разные адреса в web.config.Поэтому важно использовать разные адреса = конфигурации для каждой конечной точки (пример в 1-м посте).Одна конечная точка может пропустить это или оставить это пустым.Все остальные нуждаются в этом.

0 голосов
/ 06 июня 2012

Просто чтобы добавить к этому обсуждению.

Я столкнулся с той же проблемой, и в итоге я использовал частичный класс.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...