Как построить сервис WCF, который раскрывает уровень вашего бизнеса?

Question

WCF продвигает хороший дизайн, используя интерфейсы, контракты и т. Д. Меня удивляет то, что, например, в моем случае, если у меня есть 2 набора бизнес-функций, таких как ICustomerMgmtBIZ и IProductMgmtBiz. Если эти два являются ServiceContracts, и у меня есть интерфейс как

IBusinessService: IProductMgmtBIZ, ICustomerMgmtBIZ

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

Итак, прямо скажем, может ли служба WCF иметь только 1 реализацию и 1 контракт на обслуживание ??

Answer 1

Нет, можно реализовать более одного контракта на обслуживание для типа службы WCF (класса, который приписывается атрибуту ServiceBehavior), поскольку это всего лишь вопрос того, чтобы класс реализовывал несколько интерфейсов. Если вы используете какой-либо из шаблонов Visual Studio или другие виды генераторов кода, это может быть не совсем понятно. Однако, несмотря на то, что вы можете реализовать более одного интерфейса контракта на обслуживание для одного типа сервиса, это не принесет вам большой пользы, если вам нужно, чтобы сервис, предположительно, в данном случае, синглтон, работал как один сервис. IBusinessService подразумевает, что вам необходимо, чтобы все функциональные возможности службы могли вызываться из одного клиентского прокси-сервера, чтобы все операции могли работать в одном логическом сеансе (аналогично веб-сеансу ASPX). Если это не так, тогда вы можете определить отдельные прокси для каждого интерфейса контракта, но для этого также потребуется поддержка одной конечной точки для каждого контракта.

Это абсолютное требование, которое вы можете иметь только для экземпляра WCF ServiceHost для своей реализации? Какие факторы влияют на ваше решение?

Кстати, частичные занятия меня больше не беспокоят. Идея разбить код на несколько файлов сейчас кажется довольно естественной. Например, хранение частичных классов в файлах, таких как ServiceType_IProductMgmtBiz.cs и ServiceType_ICustomerMgmtBIZ.cs, кажется достаточно естественным, в дополнение к хранению логики ядра в ServiceType.cs.

Наконец, может пригодиться следующий вопрос ... WCF и наследование интерфейса - это ужасная вещь?

Answer 2

Грубо говоря, нет - вроде как - да, но. Любой обходной путь неоптимален и включает использование «IBlank» в качестве основного интерфейса WCF (где ваши интерфейсы наследуются от IBlank) и две конечные точки, одна из которых реализует IProductMgmtBIZ, а другая - ICustomerMgmtBIZ. У меня нет моей машины для разработки, это может включать некоторые другие изменения. Итак, на уровне WCF вы облажались, если не хотите иметь два ServiceHosts WCF (что вполне разумно).

Короче говоря, обходной путь неэлегатный. Проще иметь две конечные точки WCF на одном порту с другим расширением.