Большой интерфейс WCF на одном адресе конечной точки

Question

У меня есть служба wcf, которая предоставляет довольно большое количество методов службы для одного адреса конечной точки. До настоящего времени все методы обслуживания реализованы в одном классе контракта на обслуживание. Этот класс контракта на обслуживание реализует несколько интерфейсов контракта на обслуживание. Теперь я хотел бы разделить реализацию методов контракта на обслуживание на несколько классов, чтобы избежать роста класса контракта до большого. Я использую сценарий самостоятельного хостинга с ServiceHost. ServiceHost просто принимает тип одного единственного типа, реализующего методы службы, поэтому кажется, что все должно быть реализовано в этом классе. Конечно, методы могут быть разбиты на несколько классов. Но есть ли способ разделить методы на несколько классов?

Answer 1

Вы можете реализовать службу как частичный класс , который позволяет разделить реализацию на несколько файлов.

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

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

Answer 2

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

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

Клиентская сторона может быть просто воссоздана с помощью новых служб, но я думаю, что также должна быть возможность просто изменить адреса для конечных точек, и это должно работать.

Answer 3

Вы можете создать столько контрактов на обслуживание, сколько пожелаете, каждый со своей логикой.

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

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