Как разделить веб-сервис на классы?

Question

[Hoobert]

Есть некое приложение которое общается с веб-сервисом. Это приложение поддерживает загрузку плагинов, которые тоже могут обращаться к веб-сервису.


Проблема: класс веб-сервиса содержит как методы основного приложения, вроде «получить пользователя приложения», так и совсем левые методы для плагинов вроде «получить список организаторов мероприятия в определенном городе».


Хочется отделить мух от котлет и не сваливать все в один класс, но не хочется публиковать отдельные сервисы для каждого плагина.


Попробовал вариант с пространствами имен, типа такого:

[ServiceContract(Namespace = "http://organisation.ru/basicoperations")]
public interface IBasicOperations
...
[ServiceContract(Namespace = "http://organisation.ru/extendedoperations")]
public interface IExtendedOperations
...

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

Answer 1

[lair]

Хочется отделить мух от котлет и не сваливать все в один класс, но не хочется публиковать отдельные сервисы для каждого плагина.

Вот эта посылка — неверна. Если уж вы хотите разделить ответственность между классами, то и между сервисами ее неплохо бы разделить. Low-cohesion-сервис — не меньшее зло, чем low-cohesion-класс.

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

Ну вообще (если отвлечься от SRP), имеем дело со стандартным шаблоном facade. Ваш «один класс на сервере» — это фасад, он ничего не делает, а просто перенаправляет вызовы в соответствующие конкретные классы.

Но, повторюсь, это не ваш случай.

Comments

[Hoobert]

Понятно. Значит буду создавать дополнительные сервисы.

Answer 2

[neru]

Вам хочется и рыбку съесть и ни на что не сесть :))))

Пишите тогда один метод с одним входным параметром типа System.Object и разбором этого хозяйства внутри для дальнейшей рефлексии (как вариант) и вызова нужных методов нужных классов с необходимыми параметрами.