Ссылки с помощью веб-службы WCF

Раньше я пользовался веб-сервисами и понимаю их концепцию. Однако теперь я настроил веб-сервис WCF, но у меня есть вопрос по поводу его использования. (В том, как настраивается учебник.)

У меня настроено следующее:

  • Библиотека службы WCF (называемая CalculatorService)
  • Хост службы (называется CalculatorServiceHost)
  • Прокси-сервер службы (называется CalculatorServiceProxy, использует ClientBase)
  • Клиент службы (называемый CalculatorServiceClient)

Насколько я понимаю, это так:

  1. Сервисная библиотека содержит сервис / объект, который можно использовать в веб-сервисе. Допустим, это калькулятор с добавлением метода.
  2. Хост делает этот класс с его функциями доступными для клиентской стороны.
  3. Прокси-сервер отправляет и получает сообщение от клиента к настроенной конечной точке.
  4. Клиент может вызывать функции из службы через прокси.

Учебник настраивает прокси следующим образом:

public class MyCalculatorServiceProxy : ClientBase<ICalculator>, ICalculator {
    public int Add(int num1, int num2){
        return base.Channel.Add(num1, num2);
    }
}

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

В этом руководстве интерфейс и класс / служба, наследующие интерфейс, находятся в одной сборке. Таким образом, ссылка на сборку интерфейса на стороне клиента означает, что вы также можете создать экземпляр класса «Калькулятор» и даже не нуждаетесь в службе WCF для вызова функций.

Означает ли это, что вам всегда нужны две сборки со службами WCF. Один с интерфейсами, а другой с классами / услугами?

Поправьте меня, если я ошибаюсь или у кого-то есть дополнительная информация / комментарии.


person Revils    schedule 27.02.2016    source источник
comment
Да, по сути, вы всегда должны разделять контракты и операционные вещи. Контракты как интерфейс, запросы и ответы   -  person Manuel Zelenka    schedule 27.02.2016
comment
Нет, вы можете иметь контракт на обслуживание и реализацию службы в одной сборке. Иногда бывает полезно разделить их - например, на работе у нас есть сервисные контракты (интерфейсы) в отдельной сборке. Это позволяет клиентам ссылаться на сборку и использовать ChannelFactory<T> для создания прокси для клиента. Но совершенно законно иметь их обоих в одной сборке.   -  person Tim    schedule 28.02.2016
comment
Вам не нужно ссылаться на сборку калькулятора, вы можете использовать wsdl для создания прокси. Или, если служба wcf предоставляет метаданные, вы можете добавить веб-ссылку, и она создаст прокси. Но я бы порекомендовал разделить контракты и классы poco на их собственную сборку, чтобы на них можно было ссылаться как на клиенте, так и на сервере.   -  person Janne Matikainen    schedule 28.02.2016
comment
@Tim, но мне интересно, если вы ссылаетесь на сборку с сервисными контрактами и реализацией. Зачем использовать сервисы через веб-сервис через прокси. Можно ли сразу вызывать функции через ссылку на другую сборку?   -  person Revils    schedule 28.02.2016
comment
@JanneMatikainen Я изучил это и действительно создал прокси через ссылку на службу (WSDL), а не через ссылку на сборку. Это работает, хотя нужно было установить версию политики для метаданных! Спасибо, это было то, что я искал. (Можете перефразировать свой комментарий как ответ, чтобы я его принял!)   -  person Revils    schedule 28.02.2016


Ответы (1)


@Tim, но мне интересно, если вы ссылаетесь на сборку с сервисными контрактами и реализацией. Зачем использовать сервисы через веб-сервис через прокси. Можно ли сразу вызывать функции через ссылку на другую сборку?

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

Но это отлично подходит для написания модульных и интеграционных тестов.

person Scott Hannen    schedule 08.03.2016
comment
Мой комментарий не об этом. Мой комментарий о том, что у меня есть частный код, и я не хочу делиться им с клиентом. Это можно сделать через веб-сервис. Но у меня вопрос в том, зачем вам это делать, если вам нужно ссылаться на это и вы можете сразу это назвать. Однако Янне Матикайнен дал хороший ответ / предложение. - person Revils; 08.03.2016