Vi que no guj2 os VOs tem apenas os getters e setters.
O guj2 segue os conseitos de anemic model?
Nao confundir VO com Bean. VOs sao JavaBeans “burros”, sem codigo. Num dominio rico, vc nao usaria VOs, mas sim JavaBeans.
[quote=“fabriciogiordani”]Vi que no guj2 os VOs tem apenas os getters e setters.
O guj2 segue os conceitos de anemic model?[/quote]
Sim. 
Bom, antes que comecem a dizer por aí que usar VOs são prejudiciais à saúde, que eles causam hipertensão arterial e afins, VOs são úteis quando você precisa encapsular dados obtidos através de fontes remotas, diminuindo a quantidade de “transações” e aumentando a performance na obtenção de dados. E só!
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
Então o modelo anêmico seria ideal para trabalhar com EJB.
Estou certo?
[quote=“fabriciogiordani”]Então o modelo anêmico seria ideal para trabalhar com EJB.
Estou certo?[/quote]
Não. O modelo anêmico nunca é ideal. O que eu quis dizer é que VOs só servem para encapsular dados para transferi-los de um ponto a outro da sua aplicação quando você usa mecanismos distribuídos de acesso a dados.
Eu procuro constantemente aprender coisas novas em java. Eu gosto bastante de aprender design patterns. Eu entendo o MVC mas não conseguir absorver completamente a forma como ele é aplicado.
Depois de ler esse tópico conclui que um dos gurus (leia-se: cv, DQO e CIA.) do java, ou todos eles, deveriam escrever um artigo sobre o assunto como resultado dessa discusão. No GUJ encontramos muitos artigos interessantes mas não tem nenhum sobre MVC genérico (Tem um que fala de MVC com WebWork)! :-o Acho que seria de grande utilidade para a comunidade um artigo que deixasse claro como usar o MVC idependente até da linguagem OO utilizada. 
Alguém topa? :roll:
Sugestão anotada. Aliás, bem que vocês poderiam mexer um pouco mais suas bundas e começar a escrever algumas coisas para o GUJ também, né? Não sei se vocês sabem, mas escrevendo artigos para o GUJ vocês correm sérios riscos de ganherem vale-livros da Livraria Tempo Real (livros na faixa -ou quase, dependendo do preço do livro), aprenderem melhor sobre um determinado assunto (já que, para escrever sobre algo, você precisa pesquisar e estudar para colocar com suas palavras aquilo que você aprendeu), além de se tornarem celebridades do GUJ 
Lendo os comentários de cv e os demais posts deste thread refleti um pouco mais sobre o design de uma aplicação em que estou trabalhando e cheguei a algumas conclusões que gostaria de expor:
Até o momento, uma grande parte da lógica de negócios do já desenvolvi está codificada em Stateless Session Beans. Outra grande parte está implementada em modelos e controladores de MVC na interface gráfica Swing da aplicação. Ou seja, não há nada nos objetos reais do domínio.
As regras que estão nos modelos e controladores do MVC são basicamente para controlar a entrada de dados na aplicação e facilitar o preenchimento de formulários. Com base nas sugestões do cv estou pensando em maneiras de move-las para dentro objetos de domínio. Principalmente porque algumas dessas regras são validações complexas da associação entre certos objetos e implicam em acessos a um ou mais Session Beans para executar métodos de pesquisa.
Parece-me mais adequado deixar em Session Beans regras de negócio que tenham um impacto mais global sobre a aplicação, como por exemplo um controle de saldos de estoque:
Supondo que tivéssemos um objeto que representasse um lançamento de estoque (débito ou crédito) poderíamos ter um Session Bean com um método addLancamento que além de cuidar da persistência do objeto poderá fazer um cálculo de preço médio para um produto associado ao lançamento.
Isso porque um “estoque” é algo de certa forma “global” no sistema. Qualquer aplicação cliente poderá acessar o Session Bean do estoque para obter o saldo atual de um produto.
Podemos então, ver que existem outras regras que ficam “isoladas” nas instâncias dos objetos a que dizem respeito. Por exemplo: Se para adicionarmos um objeto produto a um objeto venda precisamos verificar antes a sua disponibilidade de estoque, esse código poderá ser colocado no próprio objeto venda (que obviamente acessará o Session Bean do estoque para consultar). Essa verificação diz respeito somente a uma venda, e não interessa para a aplicação como um todo. Esse objeto venda só terá um impacto maior quando for persistido por um método de um outro Session Bean que também vai se encarregar de criar lançamentos de estoque correspondentes (de débito) e adiciona-los ao estoque usando o método addLancamento que comentei antes.
Bem … apesar desse raciocínio todo ter uma certa lógica, não consigo imaginar que outros tipos de regras eu conseguiria encaixar nos objetos de domínio além das mais diversas validações que podem existir em um sistema.
São muitas as divagações possíveis à cerca desse assunto, e por isso termino esse post aqui.
Comentários serão muito bem vindos.
[]’s
Gabriel C. Oliveira
Gabriel, esqueca um pouco a historia dos Session Beans (isso é detalhe de implementação, afinal, basta dizer que é um objeto remoto, ou um “serviço”).
O importante, no seu caso, é determinar quais operações devem ser executadas no servidor (consumindo, assim, mais CPU e menos rede) e quais devem ser executadas no cliente (consumindo menos CPU e mais rede). Geralmente, as operacoes mais legais de se executar no cliente sao aquelas curtinhas, meio-do-caminho, como adicionar um produto a uma venda que ainda nao foi finalizada. A operacao de finalizar a venda, no entanto, eh algo ideal para se fazer no servidor: alem de vc ter a chance de persistir tudo de uma vez, comitar a transacao e ainda fazer mais umas continhas no meio do caminho, vc economiza bastante no quesito largura de rede, e ainda deixa o usuario trabalhar com o sistema caso haja algum problema com o servidor.
Me parece que vc esqueceu de desenhar o “estoque” como um objeto de dominio… será?
Bem, entendo …
Na verdade o meu objeto de domínio para o estoque seria o próprio EJB. Mas eu também poderia criar um objeto de domínio no mesmo nível dos demais que internamente usaria o EJB para executar as suas operações.
[]'s
Gabriel C. Oliveira
Sinto que esse tópico ainda vai mais longe.
Uma vez que tenhamos um domínio de objetos rico, com uma quantidade significativa de regras de negócio que não fossem implementados na forma de EJBs, mas ao contrário disso fizessem uso de EJBs de sessão e outros em um servidor de aplicação qualquer, como ficaria a “plugabilidade” de diferentes interfaces com o usuário?
Se tais objetos de domínio estiverem dentro de uma aplicação cliente Swing por exemplo, não estaríamos unindo as regras de negócio à interface? Ou seria o caso de pensar em uma 4a. camada?
Por outro lado … se não tivéssemos o domínio de objetos próximo da interface, seria difícil implementar um MVC com eles, seja para uma interface Swing, ou seja para Web …
Entre tantas divagações, começo a pensar ser utópico um cenário onde a interface possa ser totalmente separada do domínio de objetos.
Alguém concorda?
Reescreva isso como:
“Se tais objetos de dominio forem usados dentro de uma aplicacao cliente Swing por exemplo, nao estariamos unindo as regras de negócio à interface?”
E a resposta fica clara dentro da própria pergunta: não, a UI é apenas cliente dos servicos oferecidos pelo domínio. 