Encapsulamento

O ActiveRecord (do Ruby On Rails, nao o Pattern) faz algo mais ou menos assim (traduzindo pra Java, e eu nao sei se acertei na sintaxe um-ponto-cincozenta):

dai, em algum outro lugar....

Fica bonitinho, IMHO

Olá,

Interessante esta abordagem. Recentemente montei uma arquitetura pra um sistema que to fazendo e tinha feito algo semelhante.
A parte do save, update, etc eu fiz deste jeito mesmo sem VO e direto no proprio Bean, usando uns commands pra isso. Algo tipo:

Onde este atributo session é a implementacao de um interface que criei e tem somente os atributos save, update, delete, get e find. Somente ela reconhece o Dao.
Para a parte das consultas tava usando um ValueListHandle que era usado pelo meu Bean para realizar os find com as restricoes mais especificas. Nao ta gostando pq ia ter que ficar criando as classes do ValueListHandle dentro do bean e propagar a Session. Do jeito que o CV mostrou acho que resolvo meu problema com poucas alteracoes.

O que acham desse modelo?

]['s

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Poxa, chiquérrimo usando Generics. Ainda não me acostumei a pensar solução utilizando este recurso.

*babando*

Contudo, por que um objeto Candidato deveria ser responsável por buscar coleções de outros Candidatos? Por que ele deveria guardar informação sobre qual tipo de Candidato o usuário quer buscar?

E, nesse modelo, como sera possível alterar a classe Base para uma estrutura completamente diferente, baseado numa interface? Não seria melhor algo como

sendo Base uma Interface?

cv, obrigadíssimo pelo exemplo, vou usá-lo

O problema de fazer usando delegacao ao inves de heranca eh que vc tem que declarar os metodos estaticos

Eu nao sei se rola usar generics em metodos estaticos, alias... se nao der, a ideia do ActiveRecord nao fica tao legal, mas mesmo assim da pra aproveitar.

Por ultimo, concordo que usar um objeto Candidato pra buscar outros, mas usar a classe Candidato pra buscar fica chique - metodos estaticos bonitinhos e tal

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Ah gostei

fez sentido pra mim \o/ eeee

Obrigado mesmo cv

Agora o problema grave é mandar esse mega bombado objeto pela rede hehe que tal usar DTO?
*é esafqueaod por shoes*

Procurei o livro do Martim Flower, POOEOoepP, mas não encontrei nada e não vou comprar ele agora

LIPE wrote:Agora o problema grave é mandar esse mega bombado objeto pela rede hehe que tal usar DTO?
*é esafqueaod por shoes*

Tudo bonitinho pra chegar no final e querer usar DTO.
Naoooooooooooo

Fiquei so com uma duvida sobre o que o CV postou. Quando tu fala:

cv wrote:O problema de fazer usando delegacao ao inves de heranca eh que vc tem que declarar os metodos estaticos

Era sobre o que eu tinha postado ou do LIPE?

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

É sobre o próprio exemplo dele creio eu eheh

Quanto à sua implementação fabgp, quem fornecia o objeto session para os Objetos? E como você poderia colocar todos os comandos dentro de uma transação?

LIPE wrote:É sobre o próprio exemplo dele creio eu eheh

Ha, agora entendi.

LIPE wrote:Quanto à sua implementação fabgp, quem fornecia o objeto session para os Objetos? E como você poderia colocar todos os comandos dentro de uma transação?

Essa arquitetura eu usei em um sisteminha com WW, a Session ta sendo disponibilizada pela minha classe Transaction que é criada com um interceptor para as actions e ele seta na minha super-action a instancia dessa transaction.
Depois a session é passada para o bean quando vou executar algo neles.

Tem algumas coisas que nao gostei do modo que montei, mas ainda nao vi uma maneira eficiente de fazer isso. To pensando em como mudar ainda.

]['s

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Ah, você provê o objeto session via IoC, isso?

Mas assim fica bem ruim para ter um controle melhor das transações envolvidas, não? Penso assim pois no sistema atual fiz algo semelhante, e quando precisei colocar ações em transações diferentes foi meio dolorido.

LIPE wrote:Agora o problema grave é mandar esse mega bombado objeto pela rede hehe que tal usar DTO?

Precisa mesmo mandar ele pela rede? Hmm. Merda. Bom, pega o BeanUtils, taca tudo num HashMap, e passa pela rede. Depois recupera, e tchararaaaaaam!

</solucao-porca>

Se o caso for mandar um objeto pesado pela rede e isso REALMENTE for um problema, DTO eh uma boa ideia. Mas, de novo: DTO so serve quando voce tem problemas em passar um objeto pela rede. Entao, antes de usar DTO, voce precisa provar pra si mesmo que o objeto eh grande demais e vai impactar a performance da aplicacao, e olhar pro codigo e falar "argh, ta grande" nao eh uma dessas maneiras.

Um jeitinho massa de saber se voce precisa fazer um DTO ou se vc pode continuar a viver sem a ajuda de aparelhos depois da visitinha do Shoes eh serializar o objeto que vc acha que eh "gordo" demais num arquivo, e ver o tamanho dele. Depois serializar uma quantidade significativa deles, e tirar uma media. Dai da pra ter uma ideia de quantos objetos vc vai conseguir passar pela rede sem melar tudo.

LIPE wrote:Ah, você provê o objeto session via IoC, isso?

Isso.

LIPE wrote:Mas assim fica bem ruim para ter um controle melhor das transações envolvidas, não? Penso assim pois no sistema atual fiz algo semelhante, e quando precisei colocar ações em transações diferentes foi meio dolorido.

Açoes tu diz, um save e um delete por exemplo na mesma Transacao?
Nao cheguei a precisar disso, mas confesso que nem tinha pensado nessa possibilidade. Se for isso é bom eu pensar e ver o impacto disso. hehehehe
Se for isso tu achou uma solucao sem doer muito?

]['s

cv wrote:[
Um jeitinho massa de saber se voce precisa fazer um DTO ou se vc pode continuar a viver sem a ajuda de aparelhos depois da visitinha do Shoes eh serializar o objeto que vc acha que eh "gordo" demais num arquivo, e ver o tamanho dele. Depois serializar uma quantidade significativa deles, e tirar uma media. Dai da pra ter uma ideia de quantos objetos vc vai conseguir passar pela rede sem melar tudo.

Estes tempos eu fiz um teste semelhante a este, achava que tinha uma colecao de objetos extremamente "gorda", mas o java me desmentiu na lata.

]['s

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

O lance do DTO entendi

fabgt, usei uma gambiarra. Nada bonito.

Mais uma dúvida, também em relação à tarefas normalmente realizadas por um DAO: e se uma consulta retorna 2 ou mais tipos de objetos completamente diferentes? Quem deve ser repsonsável pela coisa toda?

No caso de UIs que envolvam mais de um tipo de objeto, sem problemas. Uma classe fica responsável por montar a coisa toda. Seria o mesmo princípio aplicável para o problema acima? Criar uma classe gerenciadora para esses casos especiais? Mas isso não seria um DAO?

Acho que eu nunca vi uma consulta que retorna mais de um objeto diferente, e esses objetos nao tem relacao nenhuma... ja vi umas queries que retornam um monte de itens, de imagens a blocos de texto, mas todos os itens sao... errr, uhhm, filhos da classe Item

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Tem razão

não faz o menor sentido minha pergunta