O DTO - Data Transfer Object
23/07/2013
0
Prezados colegas,
Estou colocando este tema em discussão porque ele torna a comunidade dividida. Eu uso muito o padrão DTO junto com o padrão Fachada dentro da Camada de Negócio como uma forma de isolar as camadas de Negócio e apresentação da Camada de Acesso a Dados. Porém, muitos dizem que o DTO "fere" um pouco a Orientação a Objetos, por ele ser apenas um objeto para Entrada e Saída e nada mais, não tendo muita responsabilidade e não trazer nada mais além disso. O que vocês acham sobre isso?
Estou colocando este tema em discussão porque ele torna a comunidade dividida. Eu uso muito o padrão DTO junto com o padrão Fachada dentro da Camada de Negócio como uma forma de isolar as camadas de Negócio e apresentação da Camada de Acesso a Dados. Porém, muitos dizem que o DTO "fere" um pouco a Orientação a Objetos, por ele ser apenas um objeto para Entrada e Saída e nada mais, não tendo muita responsabilidade e não trazer nada mais além disso. O que vocês acham sobre isso?
Gabriel Simas
Curtir tópico
+ 0
Responder
Posts
24/07/2013
Renato Groffe
Gabriel,
Da minha parte, eu também prefiro usar o DTO nos projetos em que desenvolvo. Acho esse padrão uma boa solução para não deixar um projeto amarrado a uma tecnologia de acesso a dados.
Já vi o pessoal usar bastante o Entity Framework diretamente. Não acho isso algo muito legal. Muitas vezes isso pode acabar em erros na manipulação de objetos, porque a conexão de acesso à base não está mais aberta.
Para evitar isso, se for o caso o caso de usar o Entity Framework, converto o que vem de um modelo gerado a partir dele em DTOs. Se o projeto no futuro for utilizar o NHiberante, as camadas de negócio e apresentação não sofrerão mudanças significativas (teoricamente tudo isso seria transparente), já modificações seriam feitas apenas na camada de acesso a dados.
Espero que isso tenha te ajudado. Não existe uma fórmula exata para tudo, mas é um caminho que acredito ser bem flexível.
Renato
Da minha parte, eu também prefiro usar o DTO nos projetos em que desenvolvo. Acho esse padrão uma boa solução para não deixar um projeto amarrado a uma tecnologia de acesso a dados.
Já vi o pessoal usar bastante o Entity Framework diretamente. Não acho isso algo muito legal. Muitas vezes isso pode acabar em erros na manipulação de objetos, porque a conexão de acesso à base não está mais aberta.
Para evitar isso, se for o caso o caso de usar o Entity Framework, converto o que vem de um modelo gerado a partir dele em DTOs. Se o projeto no futuro for utilizar o NHiberante, as camadas de negócio e apresentação não sofrerão mudanças significativas (teoricamente tudo isso seria transparente), já modificações seriam feitas apenas na camada de acesso a dados.
Espero que isso tenha te ajudado. Não existe uma fórmula exata para tudo, mas é um caminho que acredito ser bem flexível.
Renato
Responder
24/07/2013
Gabriel Simas
Gabriel,
Da minha parte, eu também prefiro usar o DTO nos projetos em que desenvolvo. Acho esse padrão uma boa solução para não deixar um projeto amarrado a uma tecnologia de acesso a dados.
Já vi o pessoal usar bastante o Entity Framework diretamente. Não acho isso algo muito legal. Muitas vezes isso pode acabar em erros na manipulação de objetos, porque a conexão de acesso à base não está mais aberta.
Para evitar isso, se for o caso o caso de usar o Entity Framework, converto o que vem de um modelo gerado a partir dele em DTOs. Se o projeto no futuro for utilizar o NHiberante, as camadas de negócio e apresentação não sofrerão mudanças significativas (teoricamente tudo isso seria transparente), já modificações seriam feitas apenas na camada de acesso a dados.
Espero que isso tenha te ajudado. Não existe uma fórmula exata para tudo, mas é um caminho que acredito ser bem flexível.
Renato
Da minha parte, eu também prefiro usar o DTO nos projetos em que desenvolvo. Acho esse padrão uma boa solução para não deixar um projeto amarrado a uma tecnologia de acesso a dados.
Já vi o pessoal usar bastante o Entity Framework diretamente. Não acho isso algo muito legal. Muitas vezes isso pode acabar em erros na manipulação de objetos, porque a conexão de acesso à base não está mais aberta.
Para evitar isso, se for o caso o caso de usar o Entity Framework, converto o que vem de um modelo gerado a partir dele em DTOs. Se o projeto no futuro for utilizar o NHiberante, as camadas de negócio e apresentação não sofrerão mudanças significativas (teoricamente tudo isso seria transparente), já modificações seriam feitas apenas na camada de acesso a dados.
Espero que isso tenha te ajudado. Não existe uma fórmula exata para tudo, mas é um caminho que acredito ser bem flexível.
Renato
Olá Renato,
Obrigado pela resposta, como você pode ver também utilizo este padrão e para mim tem sido bastante útil e protege o código definitivamente, mas como você sabe tem gente que não gosta dele pelos motivos que conversei e eu queria entender o porquê disso.
Forte Abraço
Responder
Clique aqui para fazer login e interagir na Comunidade :)
