Как я могу избавиться от указанных полей при создании прокси для службы WCF?

Question

При создании прокси-сервера из службы WCF каждый элемент типа значения, который я объявил внутри службы, создает еще одно поле типа bool в прокси-сервере. Есть ли способ избавиться от этого и продолжать совершать транзакции с сервисом?

я ниже класса описаны в эксплуатации в качестве

[DataContract] 
public class Customer 
{ 
    private int customerID; 

    [DataMember] 
    public int CustomerID 
    { 
     get { return customerID; } 
     set { customerID = value; } 
    } 
} 

при создании прокси я имею прокси-класс, как этот

public partial class Customer 
{ 
    private int customerIDField; 

    private bool customerIDFieldSpecified; 
    public int CustomerID 
    { 
     get { return this.customerIDField; } 
     set { this.customerIDField = value; } 
    } 
} 

Как я могу избавиться от члена типа BOOL customerIDFieldSpecified в прокси-сервер? а также как я могу продолжить обслуживание, только установив clientIDField.

Я хотел, чтобы мой прокси-класс, чтобы быть, как это

public partial class Customer 
{ 
    private int customerIDField; 
    public int CustomerID 
    { 
     get{ return this.customerIDField; } 
     set{ this.customerIDField = value; } 
    } 
} 

Answer 1

Как я могу избавиться от члена типа BOOL customerIDFieldSpecified в прокси-сервер?

Раньше общего с веб-службами ASMX для членов класса типа BOOL, INT, десятичной, или любого типа XSD совместимы значение открытой над границей обслуживания, чтобы эквивалентное ...FieldSpecified свойство, определенное в дополнение к фактической области для сохранения значения.

Причина, по которой это было введено в сгенерированный прокси-код, довольно проста: когда XmlSerializer сериализует типы в XML, а потому, что в .net эти типы (если они не указаны) возвращают default values, результирующая полезная нагрузка сообщения будет содержать bool или decimal/int/etc со значением false или 0 соответственно.

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

Идея заключалась в том, что если вы хотите, чтобы поле было включено, вам также необходимо было установить эквивалентное свойство FieldSpecified равным true, и это будет инструктировать XmlSerializer на стороне службы для десериализации (и, следовательно, назначения) значений в представление сервера типа. Если это не было указано, XmlSerializer пропустит эквивалентное свойство и просто переместится в следующее поле в XML.

С помощью WCF Microsoft представила DataContractSerializer в качестве замены XmlSerializer. DataContractSerializer не проявляет такого же поведения при десериализации и не будет пытаться присвоить какое-либо значение полям, которые не присутствуют в XML, поэтому это дополнительное поле больше не требуется. Однако при определенных условиях WCF возвращается к XmlSerializer, когда он генерирует код клиента из метаданных службы, что является моим предположением о том, как вы оказались с ними.