como usar Transfer Object ?

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

eu tava lendo alguns textos que falavam de transfer object, e eu vi a implementação dele...ele parece ser um javabean...é isso mesmo?
qual a diferença para um javabean?

Esso foi um dos sites q eu vi:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

http://www.guj.com.br/posts/list/28219.java

X

http://www.guj.com.br/posts/list/24281.java

Acho que já dá pra ajudar!

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

no meu caso eu tenho um servlet(controller) um bo e um dao(ambos model)...
eu quero pegar alguns dados do meu banco de dados...
então eu acesso o meu bo e depois o meu dao. O dao cria o TO e retorna para o bo que retorna para o meu servlet para que os dados possam ser exibidos...
se eu não usar um TO qual seria a alternativa?

Para que o DAO precisa criar o TO?
Retorne as informações que precisa para o BO e do BO para o Controller.

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

utilizar um TO é o modelo de implementação de DAO que está no corepatterns da sun...
qual seria sua sugestão?
usar uma collection?

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4679 Offline

Leia novamente o segundo link que o Thiago Senna postou.

Ele serve para encapsular diversas chamadas de rede numa só. Então te pergunto: seu banco de dados está fisicamente num lugar distante do local físico onde os servlets se encontram? Não? Então não precisa dessa gambiarra horrível \o/

É só uma das possibilidades de implementação do DAO. E mesmo no catálogo dos TO, eles são bem enfatizados o uso junto com EJB´s(geralmente aplicações distribuídas). Uma das principais vantagens de um TO é reduzir o tráfego de rede.
Você não precisa criar um objeto alienígena deste só pra passar de uma camada pra outra. Retorne uma Collection, ou o próprio objeto.

jdeveloper wrote:utilizar um TO é o modelo de implementação de DAO que está no corepatterns da sun...

Que são belas gambiarras para tornar EJB algo menos horrível.

Você não precisa de DTOs fora de um ambiente distribuído.

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

então eu transfiro data entre as classes através de retorno do método mesmo?
Ex.:

dentro do meu servlet ficaria assim:
List a = meuBO.getData();

dentro do meu método getData() do bo ficaria assim:
return meuDAO.getDATA();

e dentro do método getData() do meu DAO teria:

return list;

acho q ficou um pouco confuso isso q eu escrevi...mas...

Seu objeto de negócios (dica: evite esse padrão de nome de classes) acessa o DAO?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Haáaaaaaaaaaaaaaaaaaaa!!!

Para com isso.... vc me obrigou a me lembrar do dia que exibe uma arquitetura como esta como meu maior trunfo no meu projeto de final de curso!

JDeveloper, eu quando comecei aqui no guj tinha a mesma dúvida que você! Eu li o mesmo livro q vc, e cheguei nas mesmas conclusões q vc e o pior, cheguei nesta mesma arquitetura! Vc dúvida?? Veja isto entaum uma bagunça que eu tinha aprontado aqui no fórum!

http://www.guj.com.br/posts/list/21002.java
http://www.guj.com.br/posts/list/21007.java
http://www.guj.com.br/posts/list/21017.java

Então, como vc não está trabalhando em um ambiente distribuído, esqueça o TO, esqueça o BO e mandem todos eles para a pqp!

Ao invés de vc sair criando classes como AlunoTO e AlunoBO, cria uma classe aluno logo de uma vez! É muito mais elegante e mais fácil. Ele guarda dados referente ao objeto e ainda encapsula as lógicas de negócio!

Com certeza, as únicas coisas que serão úteis no seu projeto são os DAO's, e dependendo do tamanho do projeto, um AbstractFactory ou Façade já poderá ajudar bastante!

Agora pegue um pedaço de papéu e escreva 100x "Eu nunca vou usar DTO em sistemas não distribuídos!"

Abraços!
Thiago Senna

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

pcalcado wrote:Seu objeto de negócios (dica: evite esse padrão de nome de classes) acessa o DAO?

qual o problema com o nome?

Eu tenho que fazer um cadastro via web. Então o usuário preenche os campos e dá um submit.
O meu servlet pega a requisição e chama o meu bo para validar campos e etc. O bo então chama o dao para persistir os dados, caso os mesmos sejam válidos...
isso não está correto?

JavaTeenager Membro desde: 04/08/2005 08:55:58 Mensagens: 160 Offline

Thiago Senna wrote:

JDeveloper, eu quando comecei aqui no guj tinha a mesma dúvida que você! Eu li o mesmo livro q vc, e cheguei nas mesmas conclusões q vc e o pior, cheguei nesta mesma arquitetura! Vc dúvida?? Veja isto entaum uma bagunça que eu tinha aprontado aqui no fórum!

http://www.guj.com.br/posts/list/21002.java
http://www.guj.com.br/posts/list/21007.java
http://www.guj.com.br/posts/list/21017.java

Então, como vc não está trabalhando em um ambiente distribuído, esqueça o TO, esqueça o BO e mandem todos eles para a pqp!

valeu pelas sugestões de leitura... não vou mais usar dto...

Só uma coisa... vc disse pra esquecer o bo...mas não é importante ter uma camada de negócios?
o código fica bem mais organizado?

Abraços

jdeveloper wrote:
qual o problema com o nome?

Eu tenho que fazer um cadastro via web. Então o usuário preenche os campos e dá um submit.
O meu servlet pega a requisição e chama o meu bo para validar campos e etc. O bo então chama o dao para persistir os dados, caso os mesmos sejam válidos...
isso não está correto?

Funciona? Então está correto.

Só que tudo pode ser melhorado,e quanto mais você se preocupar com design do seu sistema, menos chance de virar noite dando manutenção em bugs bizarros.

Vamos devagar, do que se trata sua aplicação?

Debugger Membro desde: 05/12/2003 10:46:16 Mensagens: 57 Offline

Eu gosto de usar DTO nas minhas arquiteturas, sendo elas distribuidas ou não, por exemplo para montar frameworks vc precisa utilizar um DTO para transferir os dados de uma camada para outra abstraindo assim por exemplo qual a interface que vc utiliza e deixando a regra de negocio limpa.. utilizando apenas seus BO na camada de negócio não levando ele para a camada de interface..

Notícias, artigos e o maior fórum brasileiro sobre Java