Jak zorganizować i nazwać DTO, które są używane jako umowy danych w serwisie internetowym WCF?

Question

Używamy DTO jako umów danych w naszym serwisie internetowym WCF. Celem tych DTO jest ujawnienie tylko tych informacji, które są istotne dla konkretnej metody API.

To, czego od was szukam, to jakaś rada dotycząca najlepszych praktyk tutaj.

Na przykład rozważmy następujący prosty model:

class Order 
{ 
    int CreatedBy { get; set; } 
    DateTime CreatedOn { get; set; } 
    string Description { get; set; } 
    int Id { get; set; } 
    string Name { get; set; } 
} 

Zakładając naszą API pozwala konsumentowi Tworzenie, Aktualizacja i Get zamówienie, stworzyliśmy następujące DTOs. Atrybuty DataMember i DataContract są eliminowane ze względu na prostotę.

Tworzenie sposób: użytkownik nie może określić Id i createdon właściwości, więc DTO wygląda następująco:

class CreateOrderData 
{ 
    int CreatedBy { get; set; } 
    string Description { get; set; } 
    string Name { get; set; } 
} 

Aktualizacja metoda: Użytkownik nie może określić Id , Utworzono i Utworzono Właściwości, więc DTO wygląda następująco:

class UpdateOrderData 
{ 
    string Description { get; set; } 
    string Name { get; set; } 
} 

Get sposób: użytkownik powinien móc zobaczyć wszystko dla Zakonu, więc DTO wygląda następująco:

class OrderData 
{ 
    int CreatedBy { get; set; } 
    DateTime CreatedOn { get; set; } 
    string Description { get; set; } 
    int Id { get; set; } 
    string Name { get; set; } 
} 

Więc oto moje pytania:

• Zakładając, że w modelu Order jest więcej właściwości, a wiele z tych właściwości jest współdzielonych między DTO "Utwórz" i "Aktualizuj", czy ma to sens, aby te klasy rozciągały się od wspólnej klasy bazowej? Jeśli tak, czy DTO (OrderData) "Get" również rozszerzyć się z tej klasy? Jeśli to zrobimy, czy nie spowoduje to, że te DTO będą zbyt zależne od siebie nawzajem?

• Jeśli wszystkie właściwości są wspólne między DTO "Utwórz" i "Aktualizuj", czy powinniśmy nadal tworzyć dwa różne DTO? Jeśli tak, dlaczego? Jeśli nie, (to jest teraz tylko kwestia nazewnictwa), co należy nazwać DTO "CreateOrUpdate", aby nazwa oczywiście różniła się od "Get" DTO?

• Czy można dodać wszystkie DTO za pomocą danych takich jak "Data" lub "DataObject" lub "Dto"?

• Czy jesteśmy na dobrej drodze? Jeśli nie, w jaki sposób można ulepszyć ten projekt?

Aktualizacja:

myślę, że nie podoba ci się dziedziczenia w DTOs ponieważ klasa bazowa zostanie także wystawiony w WSDL, a klient będzie mógł go zobaczyć i oznacz ją co wydaje się brudna dla mnie (zobacz: WCF Serialization with object inheritance?). W jaki sposób używać interfejsów w DTO do wymuszania wspólnych właściwości zamiast dziedziczenia? Ponieważ DTO nie powinny mieć w sobie żadnego zachowania, nie tracimy wiele, zastępując dziedziczenie.

Answer 1

Ponieważ jest dużo o osobistych preferencji, chciałbym to zrobić ..

1. Nie chciałbym stworzyć wspólną klasę bazową ponieważ nie będzie przylegać do L w stałej. Jeśli obawiasz się DRY, możesz zamiast tego utworzyć agregację.

2. Jeśli wszystkie właściwości są wspólne, to po prostu sensowne jest utworzenie zapisu, który przyjmuje ten obiekt, klasa Dto zamówienia będzie miała właściwość kluczową, która wskazywałaby, czy jest to istniejące zamówienie, czy nie.

3. Chciałbym uzyskać przyrostek wszystkich z Dto, ponieważ wiele nazw klas Dto są takie same jak klasy domeny, stają się mylące, ponieważ będą istnieć w tej samej metodzie razem. Następnie można ozdobić swoje DTOs z DataContract (Name = „porządek”, Namespace = „htp: // Domena/..”.]. W ten sposób zostaną one wystawione na zewnątrz świata według własnych upodobań

Byłem w wielu projektach, które używają tej samej ogólnej architektury, i zazwyczaj używam AutoMappera do mapowania dtos na domenę.My to zadziałało dla mnie!