O que Camada projeto deve tela do DTO Live In?

Question

Eu tenho um projeto onde usamos a tela do DTO para encapsular os dados entre o Camada de Serviço e Camada de Apresentação . No nosso caso, a camada de apresentação é ASP.Net.

As únicas classes que sabe sobre o DTO são as classes de serviço de camada e as Páginas / Controles que chamam estes serviços e mostrar do DTO.

Os DTO são quase sempre específico Página / Controle então eu sinto que eles pertencem à camada de apresentação, mas isso significaria a camada de serviço teria que fazer referência à camada de apresentação, a fim de usar o DTO.

Eu estou quase pensando que a camada de serviço deve retornar objetos mais ricos (mas não entidades de domínio?) E, em seguida, a camada de apresentação pode levar esses objetos e mapeá-los para muito específico DTO para cada preocupação Página / Controle.

Aqui está uma declaração de interface e um DTO para que você possa ver o que estou falando:

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; }
}   

Editar

Aqui está outro exemplo de código para descrever um caso de uso onde o modelo de domínio não está envolvido. Talvez isso irá esclarecer as coisas um pouco. Eu acredito que eu tenha sobrecarregado o significado DTO. Eu não estou falando de um DTO para a função de transferência de um objeto sobre o fio. Estou criando DTOs para formalizar contratos entre a comunicação à minha camada de serviço.

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; }
}

Vamos dizer que a minha autenticação de repente requer um parâmetro de endereço IP. agora eu posso adicionar essa propriedade ao DTO sem ter que mudar minha interface contrato.

Eu não quero passar Entidades a minha camada de apresentação. Eu não quero que meu código por trás de ter a capacidade de ir BlogPost.AddComment(new Comment())

Answer 1

Mesmo que o caso de uso canônico para o 'DTO' é mais "objeto serializável que pode ser passado sobre o fio", neste caso você está realmente se referindo mais a 'de transferência de apresentação-objetos' ou 'vista-modelos '.

Normalmente, para os nossos projectos a resposta para onde estes vivo é onde o código 'tradução' é que mapeia o modelo de domínio DDD às classes PTO. Se isso é na camada Prensenation (talvez não tão grande uma resposta), então os pres. camada é onde eu iria declarar os OPT. Mas, mais frequentemente do que não, é o 'Serviço' que faz a tradução para você e isso significa que tanto o 'Serviço' e 'Apresentação' referências camada necessidade do OPT e que (geralmente) leva a sua declaração em separado, projeto neutro / montagem / namespace / whatever que tanto a camada de apresentação ea camada de serviço pode fazer referência.

Answer 2

Você está usando serviços reais (web ou WCF)? Se assim for, então definir os DTOs na camada de serviço e o proxy criado quando você adiciona um serviço (ou web se usar velho ASMX) de referência irá conter todos os tipos DTO. Esta é a maneira mais simples de fazê-lo e mantém única acoplamento entre seu projeto ASP.NET e seu projeto de serviço - não é necessária qualquer referência directa do projecto em qualquer direção. Como você atualizar seus DTOs, tudo que você precisa fazer é atualizar a sua referência de serviço e vai expor automaticamente as atualizações para seu projeto web via a classe proxy que é gerado.

Em qualquer caso, se você está seguindo algo como um DDD abordá-lo é melhor ter seus projetos de infraestrutura (como uma interface web-específico da plataforma) referenciando os seus objetos de domínio do que vice-versa. Se você seguir o meu conselho acima, no entanto, seu projeto web não terá uma dependência direta com o projeto em tudo, o que é uma coisa boa, e certamente melhor do que ter o seu domínio rico objetos dependendo do seu projeto web (se isso fosse mesmo uma consideração - Sei que você não estava dizendo que estava fazendo isso)

.

Se seus DTOs são específicas-view, então eu iria incluí-los em seu projeto de UI. Ele deve ser realmente o trabalho do controlador para garantir que a exibição só recebe a partir do modelo que ele precisa -. No seu caso um valor a objetos com apenas os campos necessários para a visualização