Plain Old CLR Objeto vs Transferência de Dados Objeto

Question

POCO = Plain Old CLR (ou melhor: Classe) Objeto

= DTO de Transferência de Dados objecto

Neste pós há uma diferença, mas francamente mais dos blogs que li descrever POCO na forma DTO é definido:. DTO são recipientes de dados simples utilizados para a transferência de dados entre as camadas de uma aplicação

Are POCO e DTO a mesma coisa?

Answer 1

A POCO segue as regras da OOP. Deveria (mas não tem que) tem estado e comportamento. POCO vem de POJO, cunhado por Martin Fowler [ anedota aqui ]. Ele usou o POJO termo como uma maneira de torná-lo mais sexy para rejeitar o quadro implementações pesado EJB. POCO devem ser usados ??no mesmo contexto em .Net. Não deixe estruturas ditar o design do seu objeto.

único propósito de um DTO é a transferência de estado, e não deve ter nenhum comportamento. explicação ver de Martin Fowler de um DTO para um exemplo do uso desse padrão.

Aqui está a diferença: POCO descreve uma abordagem para a programação (objeto bom à moda antiga programação orientada), onde DTO é um padrão que é usado para "transferência de dados" usando objetos.

Enquanto você pode tratar POCOs como DTOs, você corre o risco de criar um anêmica modelo de domínio se você fazê-lo. Além disso, há uma incompatibilidade na estrutura, uma vez que DTOs deve ser projetado para transferência de dados, não para representar a verdadeira estrutura do domínio do negócio. O resultado disso é que DTOs tendem a ser mais plana do que o seu domínio real.

Em um domínio de qualquer complexidade razoável, você está quase sempre melhor criar POCOs domínio separadas e traduzi-las para DTOs. DDD (domínio design orientado) define o anti-corrupção camada (outro link aqui , mas melhor coisa a fazer é buy livro), que é uma estrutura boa que faz a segregação clara.

Answer 2

É provavelmente redundante para mim contribuir desde que eu já afirmou a minha posição em meu artigo de blog, mas o último parágrafo desse artigo tipo de somas coisas:

Assim, em conclusão, aprender a amar o POCO, e certifique-se que você não espalhar qualquer informação errada sobre ele que é a mesma coisa que um DTO. DTO são recipientes de dados simples utilizados para a transferência de dados entre as camadas de uma aplicação. POCOs são objetos de negócios de pleno direito com a exigência de que eles são Persistência ignorante (sem obter ou salvar métodos). Por último, se você não ter verificado o livro de Jimmy Nilsson ainda, buscá-lo a partir de suas pilhas universidade local. Tem exemplos em C # e é uma ótima leitura.

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

Answer 3

POCO é simplesmente um objeto que não tem uma dependência em um quadro externo. É simples.

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

Um DTO pode ser POCO como pode um objecto de domínio (que seria tipicamente rica em comportamento).

Tipicamente DTO são mais propensos a tomar dependências em estruturas externas (por exemplo. Atributos) para fins de serialização como tipicamente saem no limite de um sistema.

arquitecturas estilo Cebola típicos (muitas vezes usado dentro de uma abordagem largamente DDD) da camada de domínio está colocado no centro e assim os seus objectos não deve, neste ponto, têm dependências fora dessa camada.

Answer 4

Eu escrevi um artigo para esse tópico: DTO vs Valor objeto vs POCO .

Em resumo:

• DTO! = Valor objeto
• DTO ? POCO
• Valor objeto ? POCO

Answer 5

Eu acho que um DTO pode ser um POCO. DTO é mais sobre o uso do objeto enquanto POCO é mais do estilo do objeto (dissociada da conceitos de arquitetura).

Um exemplo onde um POCO é diferente algo que DTO é quando você está falando sobre POCO de dentro do seu modelo lógico modelo de domínio / negócio, que é uma representação OO agradável de seu domínio do problema. Você pode usar o POCO ao longo de toda a aplicação, mas isso poderia ter alguns efeitos colaterais como um conhecimento vazamentos indesejáveis. do DTO são por exemplo utilizados a partir da camada de serviço que os comunica com UI, os DTO são representação plana dos dados, e apenas são utilizados para proporcionar a interface com os dados, e que comunicam alterações trás para a camada de serviço. A camada de serviço é responsável por mapeamento do DTO em ambos os sentidos para os objetos de domínio POCO.

Atualizar Martin Fowler disse que esta abordagem é uma estrada pesada para tomar, e só deve ser tomada se houver um descompasso importante entre a camada de domínio ea interface do usuário.

Answer 6

Um caso de uso primário para um DTO é em retornar dados de um serviço web. Neste exemplo, POCO e DTO são equivalentes. Qualquer comportamento no POCO seria removido quando ele é retornado de um serviço web, por isso realmente não importa se ele tem ou não comportamento.

Answer 7

aqui é a regra geral: DTO == mal e indicador de software mais de engenharia. POCO == bom. padrões 'empresa' ter destruído o cérebro de um monte de pessoas no mundo Java EE. por favor não repetir o erro no .NET terra.

Answer 8

aulas DTO são usadas para dados serialize / desserializar de diferentes fontes. Quando você quiser desserializar um objeto a partir de uma fonte, não importa qual fonte externa é: serviço, arquivo, banco de dados etc. você só pode ser querer usar alguma parte de isso, mas você quer uma maneira fácil para desserializar os dados para um objeto. depois que você copiar os dados para o XModel que deseja usar. A serializer é uma bela tecnologia para carregar objetos DTO. Por quê? você só precisa de uma função para carga (deserialize) o objeto.

Answer 9

TL; DR:

Um DTO descreve o padrão de transferência de estado. faz um POCO não descrever qualquer coisa. É uma outra maneira de dizer "objeto" em OOP. Ela vem de POJO (Java), cunhado por Martin Fowler, que literalmente apenas descreve-o como um nome pomposo para 'objeto' porque 'objeto' não é muito sexy.

Um DTO é um padrão de objecto utilizado para transferir o estado entre camadas de preocupação. Eles podem ter um comportamento (ou seja, pode ser tecnicamente um poco), enquanto que o comportamento não sofrer mutação do estado. Por exemplo, pode ter um método que se serializa.

A POCO é um objeto simples, mas o que se entende por 'simples' é que ele não é especial. Significa apenas que é um objeto CLR sem um padrão implícita a ele. Um termo genérico. Não é feito para trabalhar com algum outro quadro. Portanto, se seu POCO tem [JsonProperty] ou EF decorações todo suas propriedades, por exemplo, então eu diria que não é um POCO.

Aqui alguns exemplos de diferentes tipos de padrões de objeto para comparar:

• Model View : usado para dados de modelo para uma visão. Geralmente tem anotações de dados para ajudar a ligação e validação. Em MVVM, ele também funciona como um controlador. É mais do que um DTO
• Valor objeto : usado para representar valores
• Aggregate Raiz : utilizado para gerenciar o estado e invariantes
• Manipuladores : utilizado para responder a um evento / message
• Atributos : usado como decorações para lidar com as preocupações transversais
• Serviço : utilizado para executar tarefas complexas
• Controlador : usado para fluxo de pedidos e respostas de controle
• Fábrica : usado para configurar e / ou montar objetos complexos para uso quando um construtor não é bom o suficiente. Também é usado para decisões make em que objetos precisam ser criados em tempo de execução.
• Repositório / DAO : usado para acessar dados

Estes são todos os objetos apenas, mas observe que a maioria deles são geralmente vinculados a um padrão. Então, você poderia chamá-los de "objetos" ou você poderia ser mais específico sobre a sua intenção e chamá-lo pelo que ele é. Esta é também por isso que temos padrões de projeto; para descrever conceitos complexos em algumas obras. DTO é um padrão. raiz agregada é um padrão, Model View é um padrão (por exemplo MVC & MVVM). POCO não é um padrão.

A POCO não descreve um padrão. É apenas uma maneira diferente de se referir a classes / objetos em OOP. Pense nisso como um conceito abstrato; eles podem estar se referindo a alguma coisa. IMO, há uma relação de mão única, porque embora uma vez que um objeto atinge o ponto em que só pode servir um propósito limpa, já não é um POCO. Por exemplo, uma vez que você marcar a sua classe com as decorações para fazer o trabalho com algum quadro, ele não é mais um POCO. Portanto:

• A DTO é um POCO
• A POCO não é um DTO
• uma vista de modelo é um POCO
• A POCO não é uma Model View

O ponto em fazer uma distinção entre os dois é sobre como manter os padrões de claro e consistente no esforço para preocupações não cruzadas e chumbo para acoplamento forte. Por exemplo, se você tem um objeto de negócios que tem métodos para o estado de mutação, mas também é decorado para o inferno com decorações EF para salvar a SQL Server e JsonProperty para que ele possa ser enviado de volta sobre um ponto final API. Esse objeto seria intolerante a mudança, e provavelmente iria ser cheio de variantes de propriedades (por exemplo UserId, UserPk, userkey, UserGuid, onde alguns deles são marcadas até não ser salvas no banco de dados e outros marcados até não ser serializado para JSON no ponto final API).

Então, se você fosse me dizer alguma coisa foi um DTO, então eu provavelmente iria se certificar de que nunca foi usado para outra coisa senão se movendo estado ao redor. Se você me dissesse algo era um modelo de visão, então eu provavelmente iria se certificar de que não estava sendo salvo em um banco de dados. Se você me dissesse algo era um modelo de domínio, então eu provavelmente iria se certificar de que had nenhuma dependência em qualquer coisa fora do domínio. Mas se você me disse algo foi um POCO, você realmente não iria me dizer muito em tudo.

Answer 10

Nem sequer chamá-los DTOs. Eles são chamados de Modelos .... período. Modelos nunca tem comportamento. Eu não sei quem veio com essa DTO mudo prazo, mas deve ser uma coisa .NET é tudo o que posso descobrir. Pense em vista modelos no MVC, mesmo barragem ** coisa, os modelos são usados ??para estado de transferência entre o lado servidor camadas ou durante o período de arame, eles são todos os modelos. Propriedades com dados. Estes são modelos que você passa ove o fio. Modelos, modelos modelos. É isso aí.

Gostaria que o DTO estúpido prazo seria ir longe de nosso vocabulário.