JavaBeans
Um JavaBean é uma classe que segue as convenções do JavaBeans, conforme definido pela Sun. A Wikipedia tem um resumo muito bom do que são JavaBeans :
JavaBeans são componentes de software reutilizáveis para Java que podem ser manipulados visualmente em uma ferramenta de construção. Na prática, são classes escritas na linguagem de programação Java, em conformidade com uma convenção específica. Eles são usados para encapsular muitos objetos em um único objeto (o bean), para que possam ser passados como um único objeto de bean em vez de como vários objetos individuais. Um JavaBean é um Objeto Java que pode ser serializado, possui um construtor nulo e permite acesso a propriedades usando os métodos getter e setter.
Para funcionar como uma classe JavaBean, uma classe de objeto deve obedecer a certas convenções sobre nomeação, construção e comportamento de métodos. Essas convenções tornam possível ter ferramentas que podem usar, reutilizar, substituir e conectar o JavaBeans.
As convenções necessárias são:
- A classe deve ter um construtor público padrão. Isso permite instanciação fácil nas estruturas de edição e ativação.
- As propriedades da classe devem ser acessíveis usando métodos get, set e outros (chamados métodos acessadores e métodos mutadores), seguindo uma convenção de nomenclatura padrão. Isso permite inspeção e atualização automatizadas fáceis do estado do bean nas estruturas, muitas das quais incluem editores personalizados para vários tipos de propriedades.
- A classe deve ser serializável. Isso permite que aplicativos e estruturas salvem, armazenem e restaurem com segurança o estado do bean de maneira independente da VM e da plataforma.
Como esses requisitos são amplamente expressos como convenções, e não pela implementação de interfaces, alguns desenvolvedores veem o JavaBeans como objetos Java antigos simples que seguem convenções de nomenclatura específicas.
POJO
Um Objeto Java Antigo Simples ou POJO é um termo introduzido inicialmente para designar um objeto Java simples e leve, sem implementar nenhuma javax.ejb
interface, em oposição ao EJB 2.x pesado (especialmente Entity Beans, Stateless Session Beans não são tão ruins para IMO). Hoje, o termo é usado para qualquer objeto simples, sem itens extras. Novamente, a Wikipedia faz um bom trabalho ao definir o POJO :
POJO é um acrônimo para Plain Old Java Object. O nome é usado para enfatizar que o objeto em questão é um objeto Java comum, não um objeto especial e, em particular, não um JavaBean Enterprise (especialmente antes do EJB 3). O termo foi cunhado por Martin Fowler, Rebecca Parsons e Josh MacKenzie em setembro de 2000:
"Nós nos perguntamos por que as pessoas eram tão contra o uso de objetos regulares em seus sistemas e concluímos que era porque os objetos simples não tinham um nome sofisticado. Então, demos a eles um, e ele ficou muito bem".
O termo continua o padrão de termos mais antigos para tecnologias que não usam novos recursos sofisticados, como POTS (Serviço Telefônico Antigo Simples) em telefonia e PODS (Estruturas de Dados Antigos Simples) definidos em C ++, mas usam apenas recursos da linguagem C, e POD (Plain Old Documentation) em Perl.
Provavelmente, o termo ganhou ampla aceitação devido à necessidade de um termo comum e de fácil compreensão que contrasta com estruturas de objetos complicadas. Um JavaBean é um POJO que é serializável, possui um construtor sem argumento e permite acesso a propriedades usando os métodos getter e setter. Um Enterprise JavaBean não é uma classe única, mas um modelo de componente inteiro (novamente, o EJB 3 reduz a complexidade do Enterprise JavaBeans).
À medida que os projetos que usam POJOs se tornam mais comumente usados, surgiram sistemas que fornecem aos POJOs parte da funcionalidade usada em estruturas e mais opções sobre quais áreas de funcionalidade são realmente necessárias. Hibernate e Spring são exemplos.
Objeto Valor
Um objeto de valor ou VO é um objeto como java.lang.Integer
esse que mantém valores (portanto, objetos de valor). Para uma definição mais formal, costumo me referir à descrição de Martin Fowler do Value Object :
Em Patterns of Enterprise Application Architecture, descrevi o Value Object como um objeto pequeno, como um objeto Money ou período. Sua principal propriedade é que eles sigam a semântica de valores em vez de referenciar a semântica.
Geralmente, você pode dizer a eles porque a noção de igualdade deles não se baseia na identidade; em vez disso, dois objetos de valor são iguais se todos os campos forem iguais. Embora todos os campos sejam iguais, você não precisa comparar todos os campos se um subconjunto for único - por exemplo, códigos de moeda para objetos de moeda são suficientes para testar a igualdade.
Uma heurística geral é que os objetos de valor devem ser totalmente imutáveis. Se você deseja alterar um objeto de valor, substitua-o por um novo e não tenha permissão para atualizar os valores do próprio objeto de valor - objetos de valor atualizáveis causam problemas de alias.
A literatura inicial do J2EE usava o termo objeto de valor para descrever uma noção diferente, o que eu chamo de Objeto de Transferência de Dados . Desde então, eles mudaram seu uso e, em vez disso, usam o termo Transfer Object .
Você pode encontrar mais material bom sobre objetos de valor no wiki e por Dirk Riehle .
Objeto de transferência de dados
O Data Transfer Object ou DTO é um (anti) padrão introduzido no EJB. Em vez de executar muitas chamadas remotas nos EJBs, a idéia era encapsular dados em um objeto de valor que pudesse ser transferido pela rede: um objeto de transferência de dados. A Wikipedia tem uma definição decente de objeto de transferência de dados :
O objeto de transferência de dados (DTO), anteriormente conhecido como objetos de valor ou VO, é um padrão de design usado para transferir dados entre subsistemas de aplicativos de software. Os DTOs geralmente são usados em conjunto com objetos de acesso a dados para recuperar dados de um banco de dados.
A diferença entre objetos de transferência de dados e objetos de negócios ou objetos de acesso a dados é que um DTO não possui nenhum comportamento, exceto para armazenamento e recuperação de seus próprios dados (acessadores e mutadores).
Em uma arquitetura EJB tradicional, os DTOs têm dois propósitos: primeiro, eles resolvem o problema de que os beans de entidade não são serializáveis; segundo, eles definem implicitamente uma fase de montagem em que todos os dados a serem usados pela exibição são buscados e empacotados nos DTOs antes de retornar o controle à camada de apresentação.
Portanto, para muitas pessoas, DTOs e VOs são a mesma coisa (mas Fowler usa VOs para significar outra coisa como vimos). Na maioria das vezes, eles seguem as convenções do JavaBeans e, portanto, também são JavaBeans. E todos são POJOs.