Проектирование услуг и операций в WCF - PullRequest
Новая
       21

Проектирование услуг и операций в WCF

1 голос
/ 21 января 2009

Буду признателен за некоторые рекомендации по моделированию сервисов и операций в WCF.

У меня есть ряд бизнес-доменов, в каждом из которых есть специальные методы, которые я хочу использовать поверх WCF. Я думаю, что OO view будет выглядеть примерно так: 

interface IBusinessDomain1
{
    MyClass1 Method1(...)
    MyClass2 Method2(...)
}

interface IBusinessDomain2
{
    MyClass3 Method3(...)
    MyClass4 Method4(...)
}

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

При определении услуг и операций для WCF, лучше ли было бы думать с точки зрения типов данных и способа отправки данных? Возможно, групповые методы из всех бизнес-доменов, которые должны будут работать определенным образом и использовать их в одном сервисе? Интересно, как другие люди взялись за подобные сценарии?

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

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

Спасибо заранее, Будет

1 Ответ

3 голосов
/ 21 января 2009

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

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

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

Если разные конфигурации привязки связаны с изменениями в конечной точке (например, в транспортном канале), то вы можете рассмотреть различные контракты для разных конечных точек, но у меня не складывается впечатление, что вы ищете здесь.

...