Вопрос дизайна о веб-сервисах и WCF

Question

У меня есть метод обслуживания с парой параметров, которые будут предоставлены всегда, и дополнительные параметры, которые будут меняться по именам и количеству параметров (я буду знать, какие параметры ожидать в поле ACTION)

Для решения проблемы проектирования, подобной описанной выше, я создал веб-сервис с параметрами, которые будут предоставляться всегда, и еще одним параметром, который будет принимать строку, записанную в ключе <*>.

с использованием MyServiceMethod:

Action : Action1
Param2: Hello
param3: world
Additional_Params: name<*>Jack;address<*>2 street;

(я знаю, что с помощью Action1 я получаю значения имени и адреса от человека, который использует службу)

, используя MyServiceMethod во второй раз:

Action : Action5
Param2: Hello
param3: world
Additional_Params: numOfHours<*>3;Sum<*>342;myName<*>asaf;

Я думаю, что это не лучший дизайн для веб-службы, которая принимает разные данные для каждого ДЕЙСТВИЯ, есть ли лучший способ сделать это?

Answer 1

Я не на 100% понимаю, что вы пытаетесь сделать, но если вы знаете, что Action1 всегда будет вызываться с парами имя / значение "имя" и "адрес", а также Action5 будет вызываться с "numOfHours", "Sum" и "myName", тогда я согласен с ответом @Eugarps и комментарием @Steven_Sudit. Просто выставьте их как параметры метода для каждого действия.

Если, однако, вы не знаете, какими будут переменные параметры (только то, что вы получите определенные пары имя / значение при вызове действий), то я бы по крайней мере использовал IDictionary<string, object> вместо строки , Выполнение этого означает, что вы можете избежать разбора строковых значений. Если передаваемые значения являются экземплярами ваших собственных типов (а не примитивов), то вам также потребуется использовать атрибут ServiceKnownType, чтобы сообщить о них сериализатору.

Answer 2

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

Если у вас большой набор действий, вы сможете представить, чтовы хотите сделать это как структуру данных и передать только этот параметр.

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

Answer 3

Я вроде уже ответил в комментариях, но здесь он находится в одном месте:

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

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