WCF - одиночная конечная точка веб-службы с использованием частичных классов - PullRequest
Новая
       15

WCF - одиночная конечная точка веб-службы с использованием частичных классов

1 голос
/ 01 апреля 2010

Проект, над которым я работаю, требует структуры как таковой: 

{BasePrefix}/Application/{id}/Security/Users/{userId}
{BasePrefix}/Application/{id}/Objects/{objectId}
etc.

Application.svc будет моей веб-службой WCF. Я пытался убедить их сделать: 

{BasePrefix}/Security/Application/{id}/Users/{userId}

Это позволило бы мне иметь несколько веб-служб WCF, таких как Security.svc, Objects.svc и т. Д.

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

Я видел статью о том, как это сделать, здесь: http://www.meineck.net/2008/04/wcf-hosting-multiple-wcf-services-as.html

Разработчик в этой статье работает с привязкой Net TCP, однако я не уверен, будет ли это работать с привязкой WebHttpBinding и как IIS будет обрабатывать несколько ресурсов.

Кто-нибудь делал это? Является ли статья, на которую я ссылаюсь, хорошим ресурсом? Или есть лучший альтернативный метод для достижения тех же результатов?

1 Ответ

0 голосов
/ 01 апреля 2010

Методология в связанной статье является разумной и будет работать для привязок, отличных от netTcpBinding (включая webHttpBinding, wsHttpBinding и т. Д.).

Однако я полагаю, что вы пытаетесь использовать схему перезаписи URL (возможно, с использованием свойства UriTemplate), которая немного отличается от того, о чем на самом деле говорится в этой статье. Это относится к созданию и реализации нескольких интерфейсов одной и той же службой и отображению каждого интерфейса в его собственную конечную точку .

Подход не работает с одной конечной точкой. Поэтому, если ваша конечная точка {BasePrefix}/Application, это может быть сопоставлено только с одним интерфейсом (скажем, IApplicationService) в конфигурации.

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

Вы были на правильном пути с вашей первоначальной оценкой. Если ваша схема выглядела так: 

{BasePrefix}/Security/Application/{id}/Users/{userId}
{BasePrefix}/Repository/Application/{id}/Objects/{objectId}

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

Код и конфигурация в этой статье действительно предназначены для того, чтобы один экземпляр службы мог размещать несколько конечных точек. Основная причина сделать это, если вам пришлось бы дублировать много кода между службами. К сожалению, это не ваша цель, поэтому вам придется либо настойчивее продвигать предложенную схему URI, либо иметь дело с монолитным контрактом на обслуживание (интерфейсом) и делать все возможное, чтобы поддерживать реализацию в чистоте #region директивы и / или частичные классы.

...