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

Question

Вкратце: Попытка написать сервис wcf для winform-приложения, которое вызывает хранимую процедуру на веб-сервере. Пока проблем нет - мой сервис предоставляет метод "execStp (string nameOfStoredProcedure, stpParamList parameterList)"

 [OperationContract]
        int execStp(string stpName, srsWcfLib.Utilities.stpParamList paramList);

где stpParamList - это другой класс, содержащий третий класс stpParams (который в основном содержит пару имя / значение SqlParameter

Чтобы добавить параметры в список, я написал метод во втором классе

public void addParameter(string ParamName, object ParamValue)
        {
            this._Parameters.Add(new stpParam(ParamName, ParamValue));
        } 
List<stpParam> _Parameters = new List<stpParam>();

    [DataMember]
    public List<stpParam> Parameters
    {
        get { return _Parameters; }
        set { _Parameters = value; }
    }

При создании экземпляра класса List в win-приложении

stpParamList stpParams = new stpParamList();

Я могу получить доступ stpParams.Parameters, но НЕ stpParams.addParameter (name, value);

Чего мне не хватает (очевидно) ...?

Спасибо, Reinhard

Answer 1

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

Чтобы решить эту проблему, обратитесь к той же библиотеке сущностей на клиенте и в разделе «настройка службы WCF» установите флажок «повторно использовать ссылку» для этой библиотеки.

Answer 2

Эрих решил проблему с головой: WCF - это транспортная система на основе MESSAGE , например. Вы передадите сериализованное сообщение вашего объекта. Объект на стороне сервера с любыми дополнительными функциями будет сериализован в XML или двоичный формат и передан клиенту по проводам.

Однако клиент имеет в своем распоряжении только файл XSD (XML-схема), предоставляемый вашим сервисом, - он создаст класс на стороне клиента с такой же «сигнатурой данных» на проводе, т. Е. С теми же полями, то же имя и тип - но он не может волшебным образом воссоздать какие-либо функции и / или методы, которые есть в коде на стороне сервера. Все, что он может сделать, это десериализовать сообщение (текстовое или двоичное) обратно в представление класса только для данных.

Это не ошибка или проблема привязки - это фундаментальный выбор дизайна для WCF - единственное соединение между клиентом и сервером - это сериализованное сообщение - все, что может быть представлено в схеме XML. Он с удовольствием сериализует и десериализует данные, но не может перемещать код / ​​поведение. Вы НЕ передаете фактические объекты по ссылке, как при обычном вызове функции - среда выполнения WCF сериализует ваши параметры в XML и отправляет их через.

Теперь, если вы контролируете оба конца провода, например, и клиент, и сервер, есть способ обойти это, что немного нарушает принципы SOA (но это может быть полезно). Если вы поместите свои сервисные контракты и контракты на данные в отдельную сборку Contracts.dll (библиотека классов), а затем будете ссылаться на нее как со стороны сервера, так и со стороны клиента, вы действительно можете совместно использовать общий тип .NET srsWcfLib.Utilities.stpParamList с весь его функционал. В этих случаях, однако, вам придется проделать немного больше работы на стороне клиента и создать экземпляр клиентского прокси вручную в коде (вместо того, чтобы Visual Studio или svcutil создавали клиентский прокси для вас), так как вам нужно сослаться на это сборка общих контрактов и использование их типов напрямую (вместо создания клиентских классов).

Марк