Come organizzare e denominare DTO che vengono utilizzati come contratti di dati in un servizio Web WCF

Question

Utilizziamo DTO come contratti di dati nel nostro servizio web WCF. Lo scopo di questi DTO è esporre solo le informazioni rilevanti per un metodo API specifico.

Quello che sto cercando da voi ragazzi è qualche consiglio sulle migliori pratiche qui.

Ad esempio, si consideri la seguente semplice modello:

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

Supponendo che la nostra API permette al consumatore di Creare, Aggiornamento e Ottenere un Ordine, abbiamo creato le seguenti DTOs. Gli attributi DataMember e DataContract vengono eliminati per semplicità.

Crea metodo: Un utente non può specificare il Id e createdOn proprietà, in modo che il DTO è simile al seguente:

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

Aggiornamento metodo: Un utente non può specificare il Id , CreatoOn e CreatedBy proprietà, quindi il DTO è simile al seguente:

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

Get metodo: un utente dovrebbe essere in grado di vedere tutto per l'Ordine, in modo che il DTO è simile al seguente:

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

Così qui sono le mie domande:

• Supponendo che ci siano più proprietà nel modello Ordine e molte di queste proprietà sono condivise tra DTO "Crea" e "Aggiorna", ha senso che queste classi si estendano da una classe base comune? Se sì, il DTO "Get" (OrderData) dovrebbe estendersi anche da quella classe? Se lo facciamo, non lascia questi DTO troppo dipendenti l'uno dall'altro?

• Se tutte le proprietà sono comuni tra "Crea" e "Aggiorna" DTO, dovremmo creare ancora due DTO diversi? Se sì, perché? Se no, (questa è solo una domanda di denominazione ora) che cosa dovrebbe essere chiamato il DTO "CreateOrUpdate" in modo che il nome sia ovviamente diverso dal DTO "Get"?

• È OK per suffrare tutti i DTO con qualcosa come "Dati" o "DataObject" o "Dto"?

• Siamo sulla strada giusta qui? In caso contrario, come si può rendere questo design migliore?

Aggiornamento:

Penso che non mi piace l'eredità nel DTOs perché la classe di base sarà inoltre esposto nel WSDL e il cliente sarà in grado di vederlo e un'istanza che sembra sporca a me (vedi questo: WCF Serialization with object inheritance?). Che ne dici di utilizzare le interfacce in DTO per applicare proprietà comuni anziché ereditarietà? Dal momento che le DTO non dovrebbero avere alcun comportamento in esse, non stiamo perdendo molto sostituendo l'ereditarietà.

Answer 1

Poiché si tratta di molto di preferenze personali, vorrei fare questo ..

1. non vorrei creare una classe base comune dal momento che non sarebbe aderire a L in solido. Se sei preoccupato per DRY, allora potresti creare un'aggregazione.

2. Se tutte le proprietà sono comuni, ha senso creare un Salvataggio che prende quell'oggetto, l'ordine in cui la classe Dto avrà una proprietà chiave (i) che indicherà se è un ordine esistente o meno.

3. Avrei suffisso tutto con Dto, poiché molti nomi di classe Dto sono uguali a quelli delle classi di dominio, si confondono poiché saranno presenti nello stesso metodo insieme. Poi si può decorare la vostra DTOs con DataContract (Name = "Ordine", Namespace = "htp: // yourdomain/.."..] In questo modo saranno esposti al mondo esterno in base alle proprie preferenze

Sono stato in più progetti che utilizzano la stessa architettura generale, in genere utilizzo AutoMapper per mappare da dtos a dominio. Ha funzionato perfettamente per me!