Objeto CLR antigo simples versus object de transferência de dados

POCO = Plain Old CLR (ou melhor: Class) Object

DTO = Objeto de Transferência de Dados

Neste post há uma diferença, mas francamente a maioria dos blogs que leio descrevem o POCO na forma como o DTO é definido: DTOs são contêineres de dados simples usados ​​para mover dados entre as camadas de um aplicativo.

POCO e DTO são a mesma coisa?

Um POCO segue as regras da OOP. Deve (mas não precisa) ter estado e comportamento. O POCO vem do POJO, cunhado por Martin Fowler [ anedota aqui ]. Ele usou o termo POJO como uma forma de torná-lo mais sexy para rejeitar as implementações EJB pesadas do framework. O POCO deve ser usado no mesmo contexto em .Net. Não deixe que os frameworks determinem o design do seu object.

O único propósito de um DTO é transferir o estado e não deve ter nenhum comportamento. Veja a explicação de Martin Fowler de um DTO para um exemplo do uso desse padrão.

Aqui está a diferença: o POCO descreve uma abordagem à programação (boa e velha programação orientada a objects), em que DTO é um padrão usado para “transferir dados” usando objects.

Embora você possa tratar os POCOs como DTOs, você corre o risco de criar um modelo de domínio anêmico se o fizer. Além disso, há uma incompatibilidade na estrutura, já que os DTOs devem ser projetados para transferir dados, não para representar a verdadeira estrutura do domínio de negócios. O resultado disso é que os DTOs tendem a ser mais planos do que o seu domínio real.

Em um domínio de qualquer complexidade razoável, é quase sempre melhor criar POCOs de domínio separados e traduzi-los para DTOs. DDD (domain driven design) define a camada anticorrupção (outro link aqui , mas a melhor coisa a fazer é comprar o livro ), que é uma boa estrutura que torna clara a segregação.

Provavelmente é redundante para mim contribuir desde que eu já afirmei a minha posição no artigo do meu blog, mas o parágrafo final desse artigo resume as coisas:

Então, em conclusão, aprenda a amar o POCO e certifique-se de não espalhar nenhuma informação errônea sobre ser o mesmo que um DTO. Os DTOs são contêineres de dados simples usados ​​para mover dados entre as camadas de um aplicativo. Os POCOs são objects de negócios completos com o único requisito de que sejam Persistentes Ignorantes (sem methods get ou save). Por fim, se você ainda não deu uma olhada no livro de Jimmy Nilsson, pegue-o na universidade local. Tem exemplos em C # e é uma ótima leitura.

BTW, Patrick eu li o POCO como um artigo de estilo de vida, e concordo completamente, que é um artigo fantástico. Na verdade, é uma seção do livro de Jimmy Nilsson que eu recomendei. Eu não tinha ideia de que estava disponível online. Seu livro é realmente a melhor fonte de informação que eu encontrei em POCO / DTO / Repositório / e outras práticas de desenvolvimento de DDD.

O POCO é simplesmente um object que não depende de um framework externo. É PLAIN.

Se um POCO tem comportamento ou não é irrelevante.

Um DTO talvez POCO como pode um object de domínio (que normalmente seria rico em comportamento)

Normalmente, os DTOs têm maior probabilidade de assumir dependencies em estruturas externas (por exemplo, atributos) para fins de serialização, já que normalmente eles saem no limite de um sistema.

Em arquiteturas típicas de estilo Onion (geralmente usadas dentro de uma abordagem amplamente DDD), a camada de domínio é colocada no centro e, portanto, seus objects não devem ter dependencies fora dessa camada.

Eu escrevi um artigo para esse tópico: DTO vs Value Object vs POCO .

Em resumo:

  • DTO! = Objeto Valor
  • DTO ⊂ POCO
  • Objeto Valor ⊂ POCO

Eu acho que um DTO pode ser um POCO. O DTO é mais sobre o uso do object, enquanto o POCO é mais do estilo do object (desacoplado dos conceitos de arquitetura).

Um exemplo em que um POCO é diferente do DTO é quando você está falando sobre o POCO dentro do seu modelo de domínio / modelo de lógica de negócios, que é uma boa representação OO do seu domínio de problema. Você poderia usar o POCO em todo o aplicativo, mas isso poderia ter algum efeito colateral indesejável, como vazamentos de conhecimento. Os DTOs são, por exemplo, usados ​​na Camada de Serviço com a qual a UI se comunica, os DTOs são uma representação simples dos dados e são usados ​​apenas para fornecer dados à interface do usuário e comunicar as alterações de volta à camada de serviço. A camada de serviço é responsável por mapear as duas maneiras do DTO para os objects de domínio POCO.

Atualização Martin Fowler disse que esta abordagem é um caminho pesado a tomar, e só deve ser tomada se houver um descompasso significativo entre a camada de domínio e a interface do usuário.

Aqui está a regra geral: DTO == mal e indicador de software super-engenharia. POCO == bom. padrões de ’empresa’ destruíram o cérebro de muitas pessoas no mundo Java EE. por favor, não repita o erro no .NET.

Um caso de uso principal para um DTO é o retorno de dados de um serviço da web. Neste caso, POCO e DTO são equivalentes. Qualquer comportamento no POCO será removido quando for retornado de um serviço da Web, portanto, não importa se ele tem ou não comportamento.

As classs DTO são usadas para serializar / desserializar dados de diferentes origens. Quando você quer desserializar um object de uma fonte, não importa qual fonte externa é: serviço, arquivo, database, etc. você pode querer usar apenas uma parte disso, mas deseja uma maneira fácil de desserializar esses dados para um object. Depois disso, copie esses dados para o XModel que você deseja usar. Um serializador é uma bela tecnologia para carregar objects DTO. Por quê? você só precisa de uma function para carregar (desserializar) o object.

Nem mesmo os chame de DTOs. Eles são chamados de modelos … Período. Modelos nunca têm comportamento. Eu não sei quem veio com este termo idiota DTO, mas deve ser uma coisa. NET é tudo que eu posso descobrir. Pense em modelos de visão em MVC, mesma coisa, os modelos são usados ​​para transferir o estado entre o lado do servidor de camadas ou durante o período do fio, eles são todos os modelos. Propriedades com dados. Estes são modelos que você passa no fio. Modelos, Modelos Modelos. É isso aí.

Eu queria que o estúpido termo DTO fosse embora do nosso vocabulário.