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

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

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

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

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

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

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

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

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

Заранее спасибо, Уилл


.net c# design-patterns wcf soa
person WillH    schedule 21.01.2009    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

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

person casperOne    schedule 21.01.2009
comment
Спасибо, Каспер, это полезный ответ, который дал мне кое-что для чтения. - person WillH; 23.01.2009