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

POCO = Objeto CLR antigo simples (ou melhor: classe)

DTO = Objeto de Transferência de Dados

Neste post, há uma diferença, mas, francamente, a maioria dos blogs que eu leio descreve o POCO da maneira como o DTO é definido: os DTOs são simples recipientes de dados usados ​​para mover dados entre as camadas de um aplicativo.

POCO e DTO são a mesma coisa?

Um POCO segue as regras do POO. Deveria (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 maneira de tornar mais sexy a rejeição das implementações pesadas de EJB da estrutura. O POCO deve ser usado no mesmo contexto em .Net. Não permita que estruturas ditem o design do seu objeto.

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

Aqui está a diferença: o POCO descreve uma abordagem de programação (boa programação orientada a objetos à moda antiga), em que DTO é um padrão usado para "transferir dados" usando objetos.

Embora você possa tratar 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, pois os DTOs devem ser projetados para transferir dados, não para representar a verdadeira estrutura do domínio comercial. O resultado disso é que os DTOs tendem a ser mais simples que o seu domínio real.

Em um domínio de complexidade razoável, é quase sempre melhor criar POCOs de domínio separados e traduzi-los para DTOs. DDD (design controlado por domínio) 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, pois já afirmei minha posição no artigo do meu blog, mas o parágrafo final desse artigo resume as coisas:

Portanto, em conclusão, aprenda a amar o POCO e certifique-se de não espalhar informações erradas sobre a mesma coisa que um DTO. DTOs são recipientes de dados simples usados ​​para mover dados entre as camadas de um aplicativo. Os POCOs são objetos de negócios completos com o único requisito de que eles sejam ignorantes da persistência (sem métodos de obtenção ou salvamento). Por fim, se você ainda não leu o livro de Jimmy Nilsson, compre-o nas estantes da universidade local. Tem exemplos em C # e é uma ótima leitura.

Aliás, Patrick Li o POCO como um artigo sobre estilo de vida e concordo plenamente 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 sobre POCO / DTO / Repository / e outras práticas de desenvolvimento de DDD.

O POCO é simplesmente um objeto que não depende de uma estrutura externa. É SIMPLES.

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

Um DTO pode ser POCO, assim como um objeto de domínio (que normalmente seria rico em comportamento).

Normalmente, os DTOs são mais propensos a ter dependências em estruturas externas (por exemplo, atributos) para fins de serialização, pois normalmente saem nos limites de um sistema.

Nas arquiteturas típicas do estilo Onion (geralmente usadas em uma abordagem amplamente DDD), a camada de domínio é colocada no centro e, portanto, seus objetos não devem, neste ponto, ter dependências fora dessa camada.

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

Em resumo:

• DTO! = Objeto de valor
• DTO ⊂ POCO
• Objeto de valor ⊂ POCO

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

Um exemplo em que um POCO é algo diferente do DTO é quando você está falando sobre o POCO dentro do modelo de domínio / modelo de lógica de negócios, que é uma boa representação OO do domínio do problema. Você pode usar os POCOs em todo o aplicativo, mas isso pode ter algum efeito colateral indesejável, como um vazamento de conhecimento. Os DTOs são usados, por exemplo, a partir da Camada de Serviço com a qual a interface do usuário se comunica, os DTOs são uma representação plana 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 objetos de domínio POCO.

A atualização Martin Fowler disse que essa abordagem é um caminho pesado a seguir e só deve ser adotada se houver uma incompatibilidade significativa entre a camada de domínio e a interface do usuário.

Um caso de uso primário para um DTO é retornar dados de um serviço da web. Nesse caso, POCO e DTO são equivalentes. Qualquer comportamento no POCO seria removido quando retornado de um serviço da Web, portanto, não importa se ele possui ou não comportamento.

aqui está a regra geral: DTO == mal e indicador de software com excesso de engenharia. POCO == bom. Os 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 land.

As classes DTO são usadas para serializar / desserializar dados de diferentes fontes. Quando você deseja desserializar um objeto de uma fonte, não importa qual fonte externa seja: serviço, arquivo, banco de dados etc., você pode querer usar apenas parte disso, mas deseja uma maneira fácil de desserializar esses dados para um objeto. depois disso, você copia esses dados para o XModel que deseja usar. Um serializador é uma bela tecnologia para carregar objetos DTO. Por quê? você só precisa de uma função para carregar (desserializar) o objeto.

TL; DR:

Um DTO descreve o padrão de transferência de estado. Um POCO não descreve nada. É outra maneira de dizer "objeto" no OOP. Ele vem do POJO (Java), cunhado por Martin Fowler, que literalmente o descreve como um nome mais sofisticado para 'objeto' porque 'objeto' não é muito sexy.

Um DTO é um padrão de objeto usado para transferir o estado entre as camadas de preocupação. Eles podem ter comportamento (ou seja, tecnicamente, pode ser um poco), desde que esse comportamento não mude o estado. Por exemplo, ele pode ter um método que se serializa.

Um POCO é um objeto simples, mas o que se entende por "simples" é que ele não é especial. Apenas significa que é um objeto CLR sem padrão implícito. Um termo genérico. Não foi feito para funcionar com outra estrutura. Portanto, se o seu POCO tiver[JsonProperty] decorações EF em todas as suas propriedades, por exemplo, eu diria que não é um POCO.

Aqui estão alguns exemplos de diferentes tipos de padrões de objetos para comparar:

• Ver modelo : usado para modelar dados para uma vista. Geralmente possui anotações de dados para ajudar na ligação e validação. No MVVM, ele também atua como um controlador. É mais que um DTO
• Objeto Valor : usado para representar valores
• Raiz Agregada : usada para gerenciar estado e invariantes
• Manipuladores : usados ​​para responder a um evento / mensagem
• Atributos : usados ​​como decoração para lidar com preocupações transversais
• Serviço : usado para executar tarefas complexas
• Controlador : usado para controlar o fluxo de solicitações e respostas
• Fábrica : usado para configurar e / ou montar objetos complexos para uso quando um construtor não é bom o suficiente. Também usado para tomar decisões sobre quais objetos precisam ser criados em tempo de execução.
• Repositório / DAO : usado para acessar dados

Estes são apenas objetos, mas observe que a maioria deles geralmente está vinculada a um padrão. Então você pode chamá-los de "objetos" ou pode ser mais específico sobre sua intenção e chamá-lo pelo que é. É também por isso que temos padrões de design; descrever conceitos complexos em alguns trabalhos. DTO é um padrão. A raiz agregada é um padrão, o View Model é um padrão (por exemplo, MVC e MVVM). POCO não é um padrão.

Um POCO não descreve um padrão. É apenas uma maneira diferente de se referir a classes / objetos no OOP. Pense nisso como um conceito abstrato; eles podem estar se referindo a qualquer coisa. Na IMO, existe um relacionamento unidirecional, porque, uma vez que um objeto atinge o ponto em que só pode servir a um propósito de maneira limpa, ele não é mais um POCO. Por exemplo, depois de marcar sua classe com decorações para fazê-la funcionar com alguma estrutura, ela não é mais um POCO. Portanto:

• Um DTO é um POCO
• Um POCO não é um DTO
• Um modelo de exibição é um POCO
• Um POCO não é um modelo de exibição

O objetivo de fazer uma distinção entre os dois é manter padrões claros e consistentes no esforço de não cruzar preocupações e levar a um acoplamento rígido. Por exemplo, se você possui um objeto de negócios que possui métodos para alterar o estado, mas também é decorado com decorações EF para salvar no SQL Server AND JsonProperty, para que possa ser enviado de volta por um ponto de extremidade da API. Esse objeto seria intolerante a alterações e provavelmente estaria repleto de variantes de propriedades (por exemplo, UserId, UserPk, UserKey, UserGuid, onde alguns deles estão marcados para não serem salvos no banco de dados e outros marcados para não serem serializados para JSON no terminal da API).

Então, se você me dissesse que algo era um DTO, provavelmente teria certeza de que nunca foi usado para outra coisa senão mudar o estado. Se você me dissesse que algo era um modelo de exibição, provavelmente teria certeza de que não estava sendo salvo em um banco de dados. Se você me dissesse que algo era um modelo de domínio, provavelmente teria certeza de que não dependesse de nada fora do domínio. Mas se você me dissesse que algo era um POCO, não estaria realmente me dizendo muito.

Nem os chame de DTOs. Eles são chamados de Modelos .... Período. Modelos nunca têm comportamento. Não sei quem criou esse DTO estúpido, mas deve ser uma coisa do .NET. Pense em ver modelos no MVC, mesmo problema **, os modelos são usados ​​para transferir o estado entre as camadas do lado do servidor ou durante o período de conexão, todos eles são modelos. Propriedades com dados. Esses são modelos pelos quais você passa o fio. Modelos, modelos de modelos. É isso aí.

Eu gostaria que o termo estúpido DTO se afastasse do nosso vocabulário.