WCF - instancji obiektu w DataContract konstruktora

Question

mam dwie klasy jak poniżej:

[DataContract] 
public class Address 
{ 
    [DataMember] 
    public string Line1 
    [DataMember] 
    public string Line2 
    [DataMember] 
    public string City 
    [DataMember] 
    public string State 
    [DataMember] 
    public string Zip 
} 

[DataContract] 
public class Customer 
{ 
    public Customer() 
    { 
     CustomerAddress = new Address(); 
    } 

    [DataMember] 
    public string FirstName 
    [DataMember] 
    public string LastName 
    [DataMember] 
    public Address CustomerAddress 
} 

Co się stanie, jeśli mogę wygenerować proxy mojego serwisu, który używa klasy klientów? Jeśli rozumiem koncepcję poprawnie, to myślę, że konstruktor klasy Klient nie będzie wywoływany po stronie klienta i może dawać inne zachowanie.

Jak pozbyć się tego konstruktora w klasie Klient i nadal mieć właściwość CustomerAddress typu Address, aby zachowywał się jak niemy obiekt DTO?

Jakie są ogólne wytyczne lub najlepsze praktyki stosowane przez ludzi w celu uniknięcia takiej sytuacji?

Answer 1

Jeśli używasz domyślnego DataContractSerializer do serializacji twoich obiektów, to tak, Twój konstruktor nie jest serializowany, a jakakolwiek logika, którą możesz w nim zawrzeć, nie będzie wywoływana przez twojego klienta, gdy obiekt będzie deserializowany.

Jeśli chodzi o pytanie dotyczące usunięcia logiki konstruktora i zagnieżdżenia klasy Address, to zajmie się nią DataContractSerializer. Jeśli mam kod jak poniżej:

Customer c = new Customer() { 
    FirstName = "David", 
    LastName = "Hoerster", 
    CustomerAddress = new Address() { 
    Line1 = "1 Main Street", 
    City = "Smallville", 
    State = "AA", 
    Zip = "12345" 
    } 
}; 

a następnie powrócić że z metody usługi, które Customer obiekt zostanie prawidłowo szeregowane wraz z informacjami Address. Serwer proxy wygenerowanego klienta będzie wiedział o numerze Address i będzie mógł deserializować strumień pochodzący z metody serwisowej, aby poprawnie skonstruować obiekt Customer. Twój Customer będzie fikcyjnym DTO - bez logiki, tylko właściwości.

Sprawdź Aaron Skonnard's MSDN article na Serializacji WCF, gdzie mówi o DataContractSerializer.

Answer 2

Należy lepiej zdefiniować wszystkie klasy kontraktów danych w zespole i mieć zarówno projekt serwera, jak i odwołanie do projektu klienta, tak aby można było udostępnić zachowanie inicjujące. Podczas generowania odwołania do usługi można poinstruować generator kodu, aby używał istniejących klas kontraktów danych.

Answer 3

Jeśli wygenerować klienta (przy użyciu svcutil lub „dodać odniesienie Usługa”), wówczas generowany DataContract będzie wyglądać następująco:

[DataContract] 
public class Customer 
{ 
    // empty default constructor 
    public Customer() 
    { 
    } 

    [DataMember] 
    public string FirstName 
    [DataMember] 
    public string LastName 
    [DataMember] 
    public Address CustomerAddress 
} 

Twoje dane wdrożeniowe nie zostały przeniesione. Wszystko, co jest generowane, jest tym, co trafia do WSDL, który jest w tym przypadku tylko właściwościami [DataMember].

Wspominam o tym, ponieważ pierwotne pytanie brzmi: "Co się stanie, jeśli wygeneruję proxy".

---

Jeśli jest to przedmiot jest wysyłany z serwera do klienta, to może po prostu zawsze zainicjować AdresKlienta przed wysłaniem go do klienta. W rzeczywistości, jeśli oryginalny kod znajduje się na serwerze, wówczas ten konstruktor zostanie uruchomiony, a WCF dokona serializacji CustomerAddress i zasadniczo nigdy nie wyśle ​​wartości NULL (chyba że ustawisz ją ponownie po konstruktorze).

Jeśli chcesz zrobić to tak, że klient zawsze wysyła CustomerAddress, a następnie można:

• mieć serwera czek na null, jak if(x.CustomerAddress == null) x.CustomerAddress = new Address();
• zaznaczyć DataMember wymagane, wtedy serwer zwróci błąd, jeśli klient nic nie przekazał: [DataMember(IsRequired=true)] public Address CustomerAddress;

W przeciwnym razie, nie sądzę, że istnieje jakikolwiek sposób wymuszenia generowania d Klient WCF, aby zainicjować to pole dla ciebie.