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
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! 
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.
utilizar um TO é o modelo de implementação de DAO que está no corepatterns da sun…
qual seria sua sugestão?
usar uma collection?
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.
Que são belas gambiarras para tornar EJB algo menos horrível.
Você não precisa de DTOs fora de um ambiente distribuído.
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… :roll:
Seu objeto de negócios (dica: evite esse padrão de nome de classes) acessa o DAO?
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
[quote=pcalcado]Seu objeto de negócios (dica: evite esse padrão de nome de classes) acessa o DAO?
[/quote]
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?
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
[quote=jdeveloper]
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?[/quote]
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?
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…
[quote=wellmattos]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…
[/quote]
Aí você faz:
class Usuario{
private String nome = null;
private String endereço = null;
private int idade = 0;
//gets e sets
}E tem um DTO/TO/VO:
class UsuarioVo{
private String nome = null;
private String endereço = null;
private int idade = 0;
//gets e sets
}Exatamente igual? Para que?
Para usar frameworks decentes (ou até indecentes como Struts) você não rpecisa de VO. Aliás, você só rpecisa deles numa arquitetura altamente distribuída (que as blueprints do JEE sempre prezam, mas que quase nunca acotnece no mundo real).
O que você chama de montar frameworks?
É o seguinte:
Eu tenho q fazer um sistema que faz a inscrição de um usuário online.
Então ele tem basicamente que preencher um cadastro pessoal e de acordo com o tipo de opcao de inscricao q ele escolhe o sistema exibe uma ou outra opção nas telas.
Eu pensei em fazer o seguinte:
Usar um jsp como minha camada de apresentação.
Usar um servlet como controlador.
Usar um BO e um DAO como meu model.
Então o usuário preenche o cadastro(jsp) e envia para o servlet. Esse servlet pega os dados do usuário, armazena em um objeto e envia para a minha camada de negócios para basicamente validar campos.
Se os dados digitados pelo usuário estiverem corretos eu passo esse objeto para a minha camada de negócios para q ele possa ser persistido.
Entendeu?
Isso não está correto?
Está correto. E basta um objeto Aluno, um AlunoDAO e um CadastroServlet para isso
class CadastroServlet {
public void execute() {
Aluno aluno = new Aluno();
// popula o objeto aluno com os dados da request
if( !aluno.validate() ) {
// redireciona de volta com os error
return;
}
AlunoDAO dao = new AlunoDAO();
dao.save( aluno );
// ou quem sabe
aluno.save(); // aluno que chama o DAO
}
}[quote=LIPE]Está correto. E basta um objeto Aluno, um AlunoDAO e um CadastroServlet para isso
[code]
class CadastroServlet {
public void execute() {
Aluno aluno = new Aluno();
// popula o objeto aluno com os dados da request
if( !aluno.validate() ) {
// redireciona de volta com os error
return;
}
AlunoDAO dao = new AlunoDAO();
dao.save( aluno );
// ou quem sabe
aluno.save(); // aluno que chama o DAO
}
}
[/code][/quote]
não seria melhor criar mais uma classe para validar os dados…ao invés de validar os dados dentro do servlet…?
Existem diversas maneiras de validar dados escolha a sua hehe
Eu gosto de usar strategy:
class Aluno {
private ValidationStrategy validationStrategy;
public boolean validate() {
validationStrategy.validate( this );
}
}A implementação de ValidationStrategy varia.