Советы по методу веб-сервиса WCF - PullRequest
Новая
       15

Советы по методу веб-сервиса WCF

1 голос
/ 20 апреля 2009

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

[DataContract]
    public class Status
    {
        [DataMember(Order = 0)]
        public long Code
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Message
        {
            get;
            set;
        }
    }

[DataContract]
    public class Data
    {
        [DataMember(Order = 0)]
        public string Name
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Value
        {
            get;
            set;
        }
    }

public Status InitiateTransaction(long txnTypeId, Data [] txnData);

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

Ответы [ 3 ]

2 голосов
/ 21 апреля 2009

Если люди, предлагающие вам это сделать, постыдны, скажите им, что этот шаблон - верный признак лени. Они не могут понять, какие требования предъявляются к поведению, поэтому они определяют один метод; они не могут потрудиться выяснить требования к данным, поэтому они выбирают пары имя / значение.

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

Не похоже, что у вашего примера есть такое оправдание.

1 голос
/ 24 апреля 2009

У вас также есть этот вид услуг, поскольку вы размещаете веб-сервис поверх чего-либо. Если бы вы разместили это на конечной точке SOAP, ваш клиент доставил бы вам «код» и «сообщение», которые IIS или все, что вы используете для размещения веб-службы, интерпретировали бы как сообщение HTTP и вызвали правильный обработчик HTTP. Обработчик SOAP WCF получит сообщение, которое на самом деле будет просто содержать другой набор кода и сообщения, с помощью которого стек SOAP вызовет правильный метод обслуживания и передаст сообщение этому ... который затем снова просто откроет сообщение, получите его код и сообщение и позвоните правильно.

Вы должны реализовать методы в какой-то момент в любом случае. Таким образом, вопрос, который я хотел бы задать вашим руководителям, заключается в том, почему бы не использовать общую систему кодов / сообщений, которая уже является провайдером, стандартизирована и так далее, и почему они должны тратить ваше время на то, чтобы заставить вас реализовать свой собственный ТОП?

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

1 голос
/ 20 апреля 2009

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

Но это одновременно и самая большая его слабость. Так как он настолько универсален и универсален, вы не можете на самом деле применять множество ограничений и / или проверок достоверности.

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

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

Марк

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

...