Estava pensando nestes sistemas tipo o orkut. E fiquei numa dúvida sobre como deveria modelar.
Uma das dúvidas que tive foi a respeito de "o usuário recebe e envia depoimentos". Bem, está certo que teríamos uma classe assim (acho):
public class Depoimento {
Usuario de;
Usuario para;
Date data;
String texto;
}
Mas fiquei pensando… E a classe Usuario? Acho que nao faz parte do conceito de usuario e nao tem nada a ver com suas responsabilidades os depoimentos. Tipo, acho que nao deveriamos ter nem um atributo chamado depimentos ou pior ainda, dois atributos: depoimentosEnviados e depoimentoRecebidos.
O que voces acham deste problema? Como resolveriam?
Sobre se é certo ou errado existir uma associação de Usuario para Depoimento, acho que não existe uma única resposta certa.
Conceitualmente, faz sentido um relacionamento bidirecional entre as duas entidades.
Mas isso não implica necessariamente que você precise colocar isso no seu modelo. Eu não modelaria desta forma para evitar interdependencias exageradas.
Desta forma, você pode colocar a funcionalidade que encontra os Depoimentos de um Usuario em um Serviço, e colocar um pouco mais de funcionalidade – isso é especialmente recomendado pra Recados, por exemplo. Se o seu usuário for um adolescente ele vai ter dezenas de milhares de Recados, e seu método de serviço pode implementar paginação por exemplo.
Tem uma coisa que é interessante. Se formos pensar apenas conceitualmente deixando de lado os aspectos de implementação muitas das nossas associações seriam bidirecionais. Se vivessemos em um mundo perfeito sem drawbacks de performance e banco de dados relacional seria excelente poder manter quantas relações quisessemos dessa maneira. No entanto, como não vivemos nesse mundo perfeito o ideal é manter o mínimo possível de relações bidirecionais pra não complicar a implementação. Seja com O/R ou não.
[quote=TucaZ][quote=domingos.neto]
Conceitualmente, faz sentido um relacionamento bidirecional entre as duas entidades.
[/quote]
Tem uma coisa que é interessante. Se formos pensar apenas conceitualmente deixando de lado os aspectos de implementação muitas das nossas associações seriam bidirecionais. Se vivessemos em um mundo perfeito sem drawbacks de performance e banco de dados relacional seria excelente poder manter quantas relações quisessemos dessa maneira. No entanto, como não vivemos nesse mundo perfeito o ideal é manter o mínimo possível de relações bidirecionais pra não complicar a implementação. Seja com O/R ou não.
:)[/quote]
Minha preocupação foi com a reutilização principalmente. Quem fosse usar Usuario para qualquer outra coisa teria o atributo depoimentos vazio sempre… Isso porque eu nao falei de outras coisas como os Emails/Mensagens, Scraps, etc. Usuario viraria um container de um monte de coisas!
Mas uma coisa que eu fiquei pensando ontem foi um outro relacionamento. Usuario com Perfil. Pra mim seria:
Perfil ----------> Usuario
Dai um metodo me retornaria Collection e eu poderia acessar o Usuario atraves do retorno e enviar email, por exemplo, ou mesmo escrever Depoimento.