Renato,
Nesse caso usa-se SSL pra criptografar os dados, tu nao vai deixar teu algoritmo de criptografia no cliente neh?
Imagina feito em javascript no cliente. :shock:
]['s
Entrando em criptografia que eu saiba a melhor forma de criptografar senha é usando algoritmo de hash. E que eu saiba sistemas criptográficos cujo segredo está baseado no algoritmo não são nada seguros. Hashs MD5, SHA-1, e criptografias assimétricas como RSA não são assim.
A questão é que a criptografia é um aspecto secundário, e agora estou (en)tendendo pro que o Shoes está falando. O cliente tem que criptografar a senha por causa da rede, não do banco, por isso sua idéia de usar SSL é válida, ou até mesmo um algoritmo proprietário. Ele nem de longe precisará saber como a senha é armazenada no banco, nem mesmo se ela é criptografada ou não!
PS: eu disse alguma coisa sã?
Tá meio embolado, mas a questão é por aí sim…acho
No exemplo>
A criptografia do exemplo é para armazenamento
A criptografia “na rede” seria SSL ou coisa que o valha
DTOs são classes que fazer papel do wire-format quando estamos falando de objetos distribuidos (RMI, Corba, etc).
Ou seja:
class AuthenticationBusinessDelegate {
public Principal auth(String user, String pass) {
AuthDTO dto = new AuthDTO();
dto.setUser(user);
dto.setPass(pass);
Authentication auth = //objeto EJB/CORBA/RMI/WS
AuthResultDTO res = auth.doLogin(dto);
return res.getPrincipal();
}
}DTOs não são objetos de primeira classe, mas sim amontoados de dados, por isso que eles só prestam para transmitir os dados entre os tiers.
Isso é o arroz-com-feijão-e-gororoba de tunning de EJB :lol:
Pena que não deu para participar mais ativamente deste tópico… 
Mas Philip… quero tirar algumas dúvidas quanto ao que você escreveu ai em cima.
Eu sempre imaginei que devessemos primeiramente nos preocupar com a camada de negócio, e depois a camada de apresentação + persistência. Até aqui sem problemas…
O problema mesma começa na dificuldade de ver alguma coisa funcionando. Deixe-me tentar explicar com um exemplo!!!
Numa modelagem qualquer eu criei uma classe chamada aluno. Implementado de acordo com a modelagem, ficaria mais ou menos assim:
public class Aluno {
private String nome;
private String idade;
// outros atributos
// getters and setters
public void calculaMedia() {
// corpo do metodo
}
public void salvar() {
// corpo do metodo
}
public void incluir() {
// corpo do metodo
}
public void excluir() {
// corpo do metodo
}
// outros metodos
}
Nesta caso acima é tranquilo para criar um teste e testar o metodo calculaMedia. Mas se na minha modelagem tenho os metodos incluir, excluir e etc… como faço para testá-los sem ter a persistência???
Outra dúvida seria o fato de que os métodos incluir, excluir, alterar e salvar deveriam estar em um DAO! Ou seja, eu devo colocar esses métodos na minha classe de negócio durante a modelagem???
Outra dúvidazinha!!! Se eu começar o desenvolvimento do meu sistema focando a classe de negócio, eu teria que aplicar nas minhas classes de negócio o famoso teste unitário! Até aqui tranquilo. Mas eu preciso testar DAO e Actions???
Quando você faz a modelagem você também já pensa nos DAO’s???
Abraços!!!
Thiago Senna
Creio que neste caso, você poderia fazer uma chamada ao DAO, dentro do seus métodos slvar, exluir, etc…
Oi,
Testes unitários + mock objects são uma ótima alternativa 
Não entendi o que vc quis dizer…
Você deve testar o que você acha que deve ser testado (tipo: nãot este getters e setters burros - aliás: não use getters e setters burros), mas tem outros tópicos sobre isso aqui 
Modelagem? Tipo ensinado na facudlade, milhões de diagramas?
Dica: pare de pensar na “modelagem” e pense no domínio. Você pdoe já ir pensando nos DAOs, só que é legal você se concentrar pirmeiro em resolver seu problema, através dos objetos de negócio. Infelizmente quando o sistema é grande demais, isso fica cada vez mais difícil, mas em 99% dos sistemas isso tem tudo para funcionar muito bem
[]s
Abraços!!!
Thiago Senna[/quote]
Bom, tentarei explicar melhor!
Suponha que eu tenho uma classe chamada SalaDeAula e outra chamada Aluno.
Uma sala pode conter vários alunos, correto???
Na minha classe sala eu tenho um método que retorna uma lista contendo todos os alunos desta sala. Até aqui tranquilo. JUnit resolveria meu problema.
Mas este mesmo problema poderia ser resolvido com um DAO, no qual eu passaria uma simples query com uma cláusula where. Ai eu jogaria os resultados numa collection e mandaria esta collection para minha interface gráfica.
Agora vou tentar expor realmente minha dúvida.
Quando meu action for chamado para realizar a operação de listar todos os alunos de determinada sala de aula o correto seria:
1 - Criar uma objeto Sala.
chamar o método do dao que retorna uma coleção de alunos.
colocar este coleção de aluno mo método setAlunos do objeto sala.
retornar para a interface gráfica o resultado do método sala.getAlunos()
2 -
chamar o método do dao que retorna uma coleção de alunos.
retornar para a interface gráfica o resultado.
Acabei mudando um pouco a minha dúvida… mas essa é uma dúvida que tá me encomodando pacas!!
Abraços!
Vou tentar explicar, mas eu sou tosco. O que voce quer mesmo eh ler mais sobre Domain-Driven Design, Test-Driven Design e Dependency Injection. Coisas que o google e a temporeal/amazon te ajudam bem mais que eu.
Supondo que voce tem uma Sala com varios Alunos:
Quer adicionar um novo Aluno a uma Sala? Que tal:
Aluno aluno = new Aluno.create("Rocky Balboa", sala);
aluno.save(); // insert into alunos values ('Rocky Balboa', 12);
Enfim, coisas que o Hibernate ja faz, mas com uma interface que faz sentido pro seu sistema, pras suas regras de negocio.
Então neste caso não haveriam DAO´s?O própio ‘bean’(sim, sei que este termo é infeliz mas não achei melhor) seria responsável por sua persistência?Ele mesmo faria o papel do DAO?
Eu sempre penso em ‘beans’ como entidades básicas, por exemplo Aluno seria uma entidade do sistema, porque aí toda regra de negócio eu faço utilizando um objeto Aluno.
E tenho uma classe AlunoDAO que nela eu implemento os métodos de persistência.
Olá cv, tudo jóia???
Quero direito de defesa pela alfinetada… rsrsrs… 
O google ajudaria, desde que eu soubesse que existe esse negócio de domain-driven design e que eles pudessem resolver meu problema.
Sendo assim, o problema pelo jeito é eu mesmo que não estou por dentro destes negócios todos!!! Agora com o toque que você deu, agora vou saber tirar maior proveito do Google…
No entanto, no exemplo que você citou vc usou o método aluno.create(…)
É aqui que dá um nó na minha cabeça. Essa forma que você mostrou é sem dúvida a mais elegante. Mas considerando que estou em um projeto onde o pessoal tem as classes de negócio e o DAO (dao de sql puro… nada de hibernate, IoC… blábláblá), então como fica?
1 - o método create do objeto aluno deve instanciar o DAO ?
ou
2 - o Action instância o aluno e passa ele para um DAO?
…
Desculpem-me pela ignorância… Eu acho que me polui lendo alguns livros de patterns, e acabei me convencendo de que objetos não devem ter métodos como create, save e sim que eles devem ficar no DAO. Na faculdade aprendi o contrário. Vocês dizem o contrário também Poxa? E agora??? Eu misturo tudo, ou separo!!!
Abraços!
Objetos devem ser salvos para persistirem? Não, eles devems er criados e destruídos, enquanto eles estiverem no intervalo entrte um e outro eles existem/são persistidos.
Ah, cacete, tem aquele problema: ninguém tem memória para guardar tantos objetos (o time do prevayler que o diga…), então a gente tem que guardar isso em algum lugar. Um SGBD seria ótimo para guardar estados e fazer algumas macumbas de DBA.
Ok, mas isso é uma limitação. A menos que fortemente apoiada pela linguagem (e não é o caso de java), você vai ter que colocar seus objetos de alguma forma no sgbd (ou seja lá o que você use).
Ok, então existem basicamente duas estratégias:
- O objeto se persiste
- Alguém persiste o objeto
Com o que falei de metadata+AOP (ou outra cosia parecida mas com menos voodoo)a primeira se tornaria (talvez) viável, mas puramente um objetos e persistir no banco é algo complicado.
Atualment eeu uso a estretégia de quem coordena a ação persiste. O cara vai ter que criar um objeto novo? Então após criar ele manda o objeto pro dao. Eu sicneramente acho isso um lixo, mas para aplicações “do mundo real” gerentes, project managers, rpazos e custos enchedores de saco) acho que funciona.
Eu tou usando active records, shoes, e funciona legal tambem. Em Java eh mais pentelho de implementar (mas eu cheguei a dar um exemplo pro Lipe naquela thread sobre encapsulamento… alguem linka pra mim?) de como a coisa funciona mais ou menos.
A diferenca eh que em Ruby nao tem nada da enchecao de saco :mrgreen:
E qual seria a forma ideal?
Tomando o exemplo do Thiago
[code]
public class Aluno {
private String nome;
private String idade;
// outros atributos
// getters and setters
public void calculaMedia() {
//faz um monte de coisa
// e depois tchanan
}
public void salvar(Aluno aluno) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.salvar(aluno);
}
public void listar(Aluno aluno) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.listar(aluno);
}
public void excluir(Aluno aluno) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.exluir(aluno);
}
// outros metodos
}[/code]
Essa seria uma abordagem correta , OO?
Perae, o aluno salva outro aluno (ok, eles poderiam estar colando numa prova )? Se for fazer isso, ele deveria salvar a si mesmo
Forma correta é subjetivo, abstrato, blablabla, mas considerando que estamos fazendo gambiarras de qualquer jeito, a maneira com menos código de persistência possível (dentro das outras best-practices, claro) é excelente. Seja ele qual for
Como o cv já falou, não faz sentido um Aluno ser responsável por ações que envolvem muitos Alunos. Portanto estes métodos poderiam ser estáticos
E vocês estão esquentando demais a cabeça com o lance de onde por o método que acessa o banco. Vocês leram o que o Shoes falou sobre o problema da persistência?
De qualquer maneira, no P of EAA, há a pattern indicada pelo cv, Active Record, que diz o seguinte:
Acho que vocês, assim como eu há pouco tempo, estão querendo fazer bonito, mas esqueceram que o objetivo da coisa toda é fazer algo fácil de ler, manter, reusar e estender.
[code]
public class Aluno {
private String nome;
private String idade;
private MaterialEscolar material
// outros atributos
// getters and setters
public void calculaMedia() {
//faz um monte de coisa
// e depois tchanan
}
public void salvar(MaterialEscolar material) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.salvar(material);
}
public void listar(MaterialEscolar material) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.listar(material);
}
public void excluir(MaterialEscolar material) {
//faz um monte de coisa
// e depois tchanan
Dao dao = DaoFactory.getAlunoDAO();
dao.exluir(material);
}
// outros metodos
}[/code]
Reformulando o exemplo…hehehe
Isso seria hmmmm… digamos … “correto” e OO ?
[quote=pcalcado]Ok, então existem basicamente duas estratégias:
- O objeto se persiste
- Alguém persiste o objeto
[/quote]
Sobre isso que estava pensando. Colocar código de persistência no próprio objeto, de modo que podem ser usados sem se preocupar com isso seria bom no sentido de que os usuários dos objetos não precisam se preocupar em salvar os objetos, além de tornar o código “mais OO” (mais natural?), pelo o que estou entendendo.
Mas tem aquela coisa de que no entanto nem os próprios objetos em si deveriam preocupar-se com persistência, ela deveria ser automática, visto que é uma necessidade “estrutural” e não lógica de negócio. Além disso sua lógica fica presa ao tipo de persistência usado e mesmo com abstrações ela ainda vai depender das interfaces DAO. Ou seja, código “secundário” embutido na lógica. Portanto acho que a segunda estratégia, de o usuário persistir o objeto é melhor.
Além disso sobre “colocar dados e operações sobre estes dados na mesma classe”, acho legal (pelo menos até este segundo!) manter separados os dados e a lógica. Principalmente em casos que a “lógica” da aplicação não passa de consultas, adicões e remoções de entidades no banco de dados. Ou seja, lógica que acessa a camada de persistência. Isso cria um “desacoplamento” que acho legal, porque posso fazer várias lógicas sobre os mesmos dados. Assim, minhas classes de dados (“beans burros”) não passariam de VOs/DTOs que representam as entidades do banco de dados.
Por que você acha isso um lixo? Eu não acho, como demonstrei acima.
Pois é, Renato, ams acho que esse tipo de aplicação “burra” (pega-do-banco-mostra-na-tela-volta-pro-banco) ficaria melhor feito em outra linguagem (talvez Delphi, cacete, esse topico fala do assunto do outro e o outro do assunto desse…),
[quote=renato3110]
Por que você acha isso um lixo? Eu não acho, como demonstrei acima.[/quote]
Porque simplesmente não é natural. É como DTO (Ok, não é tão horrível quanto DTO): eu uso poruqe aidna não consegui pensar e não me ensinaram nada melhor.
Fazer persistência coordenada por caso de uso é algo…sei lá…sintético demais.