[quote=LIPE]Agora o problema grave é mandar esse mega bombado objeto pela rede hehe que tal usar DTO?
é esafqueaod por shoes[/quote]
Tudo bonitinho pra chegar no final e querer usar DTO.
Naoooooooooooo :mrgreen:
Fiquei so com uma duvida sobre o que o CV postou. Quando tu fala:
Era sobre o que eu tinha postado ou do LIPE?
É 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?
Ha, agora entendi.
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
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.
Precisa mesmo mandar ele pela rede? Hmm. Merda. Bom, pega o BeanUtils, taca tudo num HashMap, e passa pela rede. Depois recupera, e tchararaaaaaam! :mrgreen:
</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.
Isso.
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? :mrgreen:
]['s
[quote=cv][
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. ;)[/quote]
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. :lol:
]['s
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 :mrgreen:
Tem razão não faz o menor sentido minha pergunta
ROFFLE LOLZOR BONUS POINTS A++++ WOULD DO BUSINESS AGAIN!!!111 pra essa camiseta do Spinal Tap :mrgreen:
Eu já, quer um bom exemplo?
Dada a seguinte query “me retorne os últimos registros que o usuario alterou”, ela não retorna os Rastros do usuario, mas sim os DO em questão.
O louds é foda
Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@
Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?
E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?
*Entrando na discussão…
Eu faria um log com os ids alterados. Depois recuperaria eles e iria em cada lugar pegar eles…
Só pra não passar em branco, eu tb uso o mesmo modelo de Bean do Fabio : cada qual herda do Master o “script de CRUD” o qual retornado, eu pego uma SessionFactory e passo pra ela executar… meio doido, mas funciona
Hnum, To usando tudo isso com Swing tah, e isso me deixa livre pra fazer uma interface pra apresentar o bean bunitinho na tela
Mas to gostando da discussão…
brlima, aconselho a ler o segundo artigo indicado pelo AllMighty. O treco é bom
Morte ao MVC!
facilmente convertido
:mrgreen:
[quote=LIPE]Morte ao MVC!
facilmente convertido[/quote]
Qual é o slogan agora? :mrgreen:
[quote=LIPE]O louds é foda
Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@
Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?
E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?[/quote]
Eu já implementei auditoria de 2 formas diferentes, cada qual tinha suas exigencias.
Uma foi usando shadow-tables, era bem facil gerar os dados de auditoria mas era uma saco usar essa informação. A outra foi usando uma tabela só com um campo clob com os valores em pares chave-valor, usa 1 tonelada de disco, mas fica mais facil de pesquisar e implementar usando interceptor do Hibernate foi assustadoramente facil.
Enfim, quanto a query, em ambos os casos os DAOs reconstruiam os DO a partir das informações recuperadas, no final das contas retornavam coleções de objetos heterogêneos mesmo. Existia um AutoriaDao que tinha esses métodos de pesquisa. Eu gosto de criar DAOs por casos de uso e não por DO que são partícipes.
E não tem full-table scan não lipe, vale lembrar que o modelo de dados e o modelo dos objetos de dominio não precisam ser parecidos ou ter coisas equivalentes, basta saber ir de um pro outro.
Então louds, o “objetivo” aqui seria não usar DAOs hehe mas sem um objeto intermediário aos dois Objetos não relacionados fica difícil.
Por isso eu nao gosto muito de mapear 1 pra 1, uma tabela pra um objeto, nem sempre isso faz sentido com a real necessidade do sistema. Esse exemplo que o Louds deu é um classico onde teu objeto nao tem nada haver com as tabelas do banco.
Acredito que o dominio do objetos deve ficar independete disso, satisfazendo a tua necessidade para as regras de negocio do sistema e o DAO que se vire pra retornar isso coerentemente.
]['s
Um bom exemplo disso é se você estiver trabalhando com OLAP ou com alguma forma de estatística, teu dominio muito provavelmente vai ter objetos que são agrupamentos de registros do banco.
A alternativa satisfatoria pro DAO, é ORM no estilo do Hibernate usando xdocklet ou annotations, uma pena apenas que ele te obriga a ter getters/setters.
Uma idéia que eu achei muito legal foi uma do Charles Miller de usar IoC para as pesquisas que o teu objeto precisa.