[quote=louds][quote=Paulo Silveira][quote=louds]
Em outra você mantem a session do hibernate escondida em um SFSB e faz lazyloading remoto.
[/quote]
Como? Na hora que ele chamar o getter do meu entity que ta desatachado ele nao vai la no SFSB pedir o restinho… O que voce estava falando nao é Java EE compliant, certo? Alias, todas as maneiras que voce citou.
[/quote]
Se você usar JPA não vai ser compliant, se usar hibernate, não influencia. O truque é você serializar a session no servidor e no cliente substituir ela por uma fachada remota.
[/quote]
Ave maria! Muito arrojado pra mim 
Mas funciona sim. Eu queria era ver se alguem descobria como fazer isso no JPA sem gambiarras…
Como sempre digo, cliente desconectado o buraco é mais em baixo…
Não consegui ler o post inteiro, mas vamos tentar ajudar:
Swing + Parte Servidora não Exige DTO
Uma prova disso é o sisteminha Bitshop que desenvolvi na minha série de artigos Design Patterns para um Mundo Real na MundoJava. Tem código fonte aqui:
http://www.aspercom.com.br/bitshop
Algumas vezes tento driblar o Lazy Load fazendo uma AppFaçade Stateful sem mandar a entidade desatachada pro cliente. (ver EmitirPedidoFacade no código). Acho que é isso que o Louds falou.
Não sei se a desculpa da Sun para usar DTO para economizar rede é um negócio 100% verdade. Não fiz nenhum benchmark e não ví nenhum que prove isso.
Um cliente Swing requer um cuidado maior com os objetos desatachados, mas não é impossível de resolver sem DTO. Geralmente eu avalio a possibilidade de colocar um lazy false senão for uma boa avalio fazer uma AppFaçade Statefull, só então recorro ao DTO.
DTO dá nojo. Não existe tamanho único. Se você for fundamentalista e sempre trabalhar com DTO e Assemblies, desenvolver o sistema é um pé no saco, principalmente porque o binding de tela não é trivial…
Falows!?
(escrevi besteira, já está editado)
Estou chegando meio tardemas…
Shoes só pra confirma uma coisa aqui.
Quando o Controller instancia o Objeto de Dominio ele acaba executando uma pouco de regra de negocio para a instanciação do Objeto de Dominio. Estas regras no caso estão dentro do construtor do Objeto de Dominio, sendo assim podemos até dizer que é o objeto de dominio que executa essas regras.
Concordas?
Oi,
Sim, é o objetod e domínio que executa. Se o fluxo originou-se de um objeto de outra camada não importa, o importante é que quem executou foi o objeto correto.
Olá pessoal do GUJ,
Nossa, li toda a discussão sobre o assunto e estou impressionado como existem pessoas que pedem opiniões, não as reflete, e pior ainda, não as aceita.
Bom mais isso não vem ao caso.
Pelo que eu entendi, nesta discussão toda e alguns artigos que li, é que o ADM do nosso guru Martin Fowler quis expressar uma preocupação que ele tem com alguns desenvolvedores que estão construindo projetos OO sem ter noção do que estão fazendo, ou por não terem compreendido corretamente os padrões(VO, TO e DTO) e seus objetivos ou simplesmente não entenderam as primícias da OO.
Ao projetar um projeto grande ou pequeno(pois isso é muito relativo do ponto de vista do ego das pessoas) umas das primeiras atividades que nós temos que ter em mente é definir o Domínio do Negócio. E o que o Martim Folwer quis dizer é que estão definindo modelos de domínio de negócio utilizando essa tríplice (VO, TO, DTO) para auxiliar na troca de mensagem dos objetos e ele definiu isso como um ADM.
Alguém por gentileza, poderia me dizer se esta conclusão está equivocada ?
Abraço à todos.
Ola, reparei que o problema aqui em discussao eh o Lazy Loading em clientes EJB3 onde as entidades estao detachadas, vi que as sugestoes do louds acabam todas por chamadas remotas com excecao da conexao aberta no cliente, o que tambem em miudos tambem acaba em conexao remota, mesmo se usarmos SFSB estaremos usando conexao remota, ou seja, de qualquer forma a conexao sera remota, e nao acho isso um problema, afinal a computacao distribuida foi feita para que conexoes remotas sejam feitas, mas o ponto aqui eh o seguinte, como fazer Lazy em entidades detachadas? Existe um framework chamada DataSlim que cria uma estrutura Lazy Loanding em qualquer ambiente inclusive no JPA e que pode ser usada em Entidades Detachadas, porem, como qualquer outra solucao ele fara um conexao remota sempre que um dado Lazy tiver que ser recuperado, porem a conexao pode ser feita para um Stateless, ou seja, nao precisamos ficar criando Stateful (que ao meu ver, sempre foi dito pra se evitar), nem abrindo transacao na camada view, o DataSlim simplesmente conecta com um Stateless que esse sim tem escopo transacional e executa o metodo responsavel por retornar os dados Lazy, ou seja, continuamos com a separacao de responsabilidade entre as camadas. Outro ponto importante quando estamos trabalhando em contextos transacionais como dentro do servidor o dataslim nao interage com o objeto entidade, ou seja, o mecanismo de Lazy pode ser usado apenas quando a entidade eh detachada, quanda a mesma ainda esta " atachada " o que vai prevalecer sera o mecanismo de Lazy do Container (Hibernate ou TopLink ) isso eh bom pois nao precisamos agora escrever clientes que precisem de qualquer alteracao quando formos usar um Framework de Persistencia ou outro.
Bom… A ideia eh mais abrangente mas espero ter dado uma ajuda.
DataSlim: http://code.google.com/p/dataslim
Olá pessoal, ainda estou com as seguintes dúvidas:
-
Como é feita a passagem dos dados do TO para o Domain Model? Via uma façade?
-
Quem que efetua as chamadas ao DAO? O Domain Model? Ou entre o DAO e o Domain Model existe uma camada?
A ideia seria uma arquitetura da seguinte forma:
View -> Controller -> Façade -> Domain Model -> DAO
E para a passagem dos valores da view para o controller e para o domain model utiliza-se um TO?
A ideia é esta? entendi direito?
Mas funciona sim. Eu queria era ver se alguem descobria como fazer isso no JPA sem gambiarras…