[quote=pafuncio]
Cara não sei se você já chegou à um entendimento, mas a questão é a mistura que você está fazendo entre a persistência e o domínio. No seu domínio, o objeto XPTO vai ser um Value Object, porém, do ponto de vista da persistência, você vai precisar de um Id (considerando esse caso), mas note bem, o ID é necessário apenas do ponto de vista da persistência, não do ponto de vista do seu domínio, logo, para o seu domínio, ele não é um Entity.[/quote]
Chamemos Key ao identificador de persistência. Pode ser um inteiro qq (ex : autonumber).
Chamemos ID à propriedade que traduz a Identidade da Entidade no sistema. Normalmente é composta de um ou mais vários campos de dados (ex. cpf).
Se existe um ID é porque é uma entidade.
VO significa que pode ser intercambiado entre duas entidades.
O exemplo do endereço.
Se E1 é o endereço da pessoa A e E2 é o endereço de B, se A e B têm no mesmo endereço então E1.equals(E2)
A e B não são ubiquos portanto têm 1 só endereço (OneToOne). Se eu fizer A.setAddress(B.getAddress())
estou dizendo que A têm agora o mesmo endereço de B.
Ao guardar no banco a tabela Pessoa tem:
a) os campos do endereço. Desta forma o objeto endereço é mapeado para campos da tabela pessoa. Isto representa implicitamente que o endereço é um VO de Pessoa
b) fazer o mesmo que (a) mas usando 2 tabelas. Pessoa tem um campo apontando o key do endereço
O endereço têm o key dele e uma foreign-key apontando pessoa (OneToOne).
Se o endereço não tiver uma foreign-key apontando pessoa será uma relação ManyToOne que viola o principio do VO. Não dá para reaproveitar o mesmo registro para E1 e E2 mesmo se eles são iguais ( se fossem entidades não so poderia como deveria).
Isto nos conduz a saber que A.setAddress() deve copiar o endereço de B para o seu e não apenas substituir a referencia.
class Pessoa
setAddress(Address a){
this.address.copyFrom(a); // isto porque o key de address não muda, só os dados
}
Esta necessidade de usar a copia indica que o endereço com duas tabelas não é realmente um VO pois não é independente de quem o usa. (Se usar só a tabela pessoa, ñ tem problema nenhum). Ou seja, o E1 e o E2 não comutáveis. Logo, isto indica que o objeto endereço
pertence à pessoa com um vinculo muito maior. Isto faz pessoa não ser apenas uma entity, mas tb um agregado.
( ou seja, um grafo em que a raiz controla os outros nodos)
c) Aqui a tabela endereço não tem key e apenas uma foreign-key para pessoa.
Pessoa não tem key apontando endereço, mas tb não precisa. Esta forma é mais saudável e semelhante a (a) pois não obriga a fazer cópias. contudo esta opção de banco identifica um OneToMany e pode dar errado se não for bem implementado.
Uma pessoa não pode ter vários endereços, já que a pessoa não existem em vários lugares ao mesmo tempo.
O que a pessoa pode ter são vários endereços classificados por finalidade (moradia,entrega, faturamento, matriz, etc…)
Neste caso existe uma classificação da relação e o modelo terá que ser: uma pessoa tem vários EndereçosClassificados. Cada EndereçoClassificado tem um endereço e uma classificação.