In quale livello di progetto dovrebbe essere attivo lo schermo DTO?

Question

Ho un progetto in cui utilizziamo i DTO dello schermo per incapsulare i dati tra il Livello di servizio e il Livello di presentazione . Nel nostro caso, il livello di presentazione è ASP.Net.

Le uniche classi che conoscono i DTO sono le classi del livello di servizio e le pagine / i controlli che chiamano questi servizi e visualizzano i DTO.

I DTO sono quasi sempre specifici per pagina / controllo, quindi ritengo che appartengano al livello di presentazione, ma ciò significherebbe che il livello di servizio dovrebbe fare riferimento al livello di presentazione per utilizzare i DTO.

Sto quasi pensando che il livello di servizio dovrebbe restituire oggetti più ricchi (ma non entità di dominio?) e quindi il livello di presentazione può prendere questi oggetti e mapparli a DTO molto specifici per ogni problema di Pagina / Controllo.

Ecco una dichiarazione di interfaccia e un DTO in modo da poter vedere di cosa sto parlando:

public interface IBlogTasks
{
    BlogPostDisplayDTO GetBlogEntryByTitleAndDate(int year, int month, string urlFriendlyTitle);
}

public class BlogPostDisplayDTO 
{
    public string Title { get; set; }
    public DateTime PostDate { get; set; }
    public string HtmlContent { get; set; }
    public string ImageUrl { get; set; }        
    public string Author { get; set; }
    public int CommentCount { get; set; }
    public string Permalink { get; set; }
}   

Modifica

Ecco un altro esempio di codice per descrivere un caso d'uso in cui il modello di dominio non è coinvolto. Forse questo chiarirà un po 'le cose. Credo di aver sovraccaricato il significato di DTO. Non sto parlando di un DTO per la funzione di trasferire un oggetto sul filo. Sto creando DTO per formalizzare i contratti tra comunicazione al mio livello di servizio.

public interface IAuthenticationTasks
{
    bool AuthenticateUser(AuthenticationFormDTO authDTO);
}

public class AuthenticationFormDTO
{
    public string UserName { get; set; }
    public string Password { get; set; }
    public bool persistLogin { get; set; }
}

Supponiamo che la mia autenticazione all'improvviso richieda un parametro dell'indirizzo IP. Ora posso aggiungere quella proprietà al DTO senza cambiare l'interfaccia del mio contratto.

Non voglio passare Entità al mio Livello presentazione. Non voglio che il mio codice sia in grado di andare BlogPost.AddComment(new Comment())

Answer 1

Anche se il caso d'uso canonico per il 'DTO' è più " oggetto serializzabile che può essere passato sul filo " ;, in questo caso ti riferisci davvero di più a 'presentation-transfer -objects "o" view-models ".

In genere per i nostri progetti la risposta a dove vivono questi è dove il codice 'traduzione' è che mappa il modello di dominio DDD alle classi PTO. Se è nel livello di Prensenation (forse una risposta non eccezionale) allora il pres. il livello è dove dichiarerei le PTO. Ma il più delle volte, è il "Servizio" che fa la traduzione per te e ciò significa che sia il livello "Servizio" sia il livello "Presentazione" hanno bisogno di riferimenti alle PTO e che (di solito) porta alla loro dichiarazione in un documento separato, progetto neutro / assembly / spazio dei nomi / qualunque cosa SIA il livello di presentazione che il livello di servizio possono quindi fare riferimento.

Answer 2

Stai utilizzando servizi reali (web o WCF)? In tal caso, quindi definire i DTO nel livello di servizio e il proxy creato quando si aggiunge un servizio (o web se si utilizza il vecchio ASMX) conterrà tutti i tipi di DTO. Questo è il modo più semplice per farlo e mantiene solo un accoppiamento libero tra il tuo progetto ASP.NET e il tuo progetto di servizio - non è richiesto alcun riferimento diretto al progetto in nessuna delle due direzioni. Man mano che aggiorni i tuoi DTO, tutto ciò che devi fare è aggiornare il riferimento del servizio e questo esporrà automaticamente gli aggiornamenti al tuo progetto web tramite la classe proxy che viene generata.

In ogni caso, se stai seguendo qualcosa come un approccio DDD, è meglio che i tuoi progetti di infrastruttura (come un'interfaccia utente specifica della piattaforma web) facciano riferimento ai tuoi oggetti di dominio piuttosto che viceversa. Se segui i miei consigli sopra, tuttavia, il tuo progetto web non avrà alcuna dipendenza diretta dal progetto, il che è una buona cosa, e sicuramente meglio che avere i tuoi oggetti di dominio ricchi a seconda del tuo progetto web (se fosse una considerazione: mi rendo conto che non stavi dicendo che lo stavi facendo).

Se i tuoi DTO sono specifici della vista, li includerei nel tuo progetto di interfaccia utente. Dovrebbe davvero essere il compito del controller di garantire che la vista ottenga dal modello solo ciò di cui ha bisogno, nel tuo caso un oggetto valore con solo i campi richiesti dalla vista.