Dúvidas MVC

Oi,

Primeiro, o Diagrama de Classes não é um modleo dinâmico, tente usar um diagrama de colaboração,a tividade ou sequência :wink:

Um exemplo de login pdoeria ser:

FORM HTML -> Servlet -> GerenciadorUsuarios -> DAO

Passando login/senha para seu Servlet, que recebe estes e localiza (JNDI, IoC, insctancia um novo objeto, o que for) um GerenciadorUsuario (não estou dizendo que você tem que ter uma classe assim, é apenas um exemplo) que tem um método:

public Usuario autenticar(String login, String senha);

O Servlet chama este método, se retornar um usuario ele o armazena em sessão.

Esse exemplo não tem muito processamento, e nada disso é responsabildiade do usuário, mas vamos supôr que você quer mudar a senha do usuário. Em vez de fazer no seu Servlet:


String senha = request.get...("senha");
String criptografada = criptografar(Senha);
usuario.setSenha(criptografada);
...

Você pode chegar a conclusão que uma senha deve ser algo secreto, só conhecido pelo usuário, que ele deve sempre retornar sua senha criptografa quando perguntarem, então faz seu servlet assim:

String senha = request.get...("senha");
usuario.novaSenha(senha);

E seu usuário, no método novaSenha(String) seria:

public void novaSenha(String s){
 this.senha=senha;
}

public String getSenha(){
 return criptografar(senha);
}

Pense nessa política de separação de responsabilidades em processamentos maiores e você vai ver o acoplamento sumindo bastante do seu código.

Toda a conversão entre HTTP/HTML e o mundo dos objetos, apenas isso. Nada de regras de negócio.

[quote=“dac”]
Quanto ao DAO… quem chamaria? O objeto Usuario? Para q ele não seja mais “burro”?[/quote]

Existem algumas técnicas para objetos chamarem seus mecanismos de persistência, mas por enquanto que inicia o processo (pode ser o método do seu façade) pode chamar, como em:

public void AtualizarUsuario(Usuario u){
 dao = new Dao();
 dao.atualizar(u);
}

Note que isso não é um requisito funcional, salvar em banco de dados é vencer uma limitação prática (não tme memória para guardar tudo na JVM), as regras de negócio (como criptografia de senha) estão implementadas nos objetos de domínio.

Shoes

Legal… antes de mais nada, obrigado pela paciencia…

O diagrama foi uma tentativa de um diagrama de componente misturado com o diagrama de classe só pra mostrar se a ideia estava coerente…

Perguntinha básica: Eu posso ter vários objetos DAO, certo? Por exemplo um DAOUsuario e um DAOCliente… certo? Só pra esclarecer…

Outra básica… meu servlet responderia diretamente para o browser ou chamaria um outro JSP para exibir o html?

Deixa eu ver se eu entendi…

Esse código ficaria no GerenciadorUsuario certo? E não no Servlet…

Mas legal… já ficou bem mais claro… valeu…

Mas ficou uma dúvida quanto ao MVC ainda…

Nestes exemplos… quem seria o Controlador?

oi,

Você mais que poder, deveria ter vários DAOs diferentes. DAOs genéricos só apra casos MUITO simples :wink:

Esqueci de falar disso!

Exceto emc asos onde não há qualquer regra de negócio sendo processada, quando é apenas alguma coisinha visual, como menus que se expandem, toda requisição HTTP deve ir para um servlet, e náo para uma JSP. Essa é uma “rule of thumb” para evitar JSPs com processamento.

Quase :slight_smile:

Esse código foi parar no próprio objeto usuário, que deixou de ser um objeto com dados que são manipulados por outros objetos e passou a ter um pouco mais de inteligência :wink:

Leia:
pcalcado.blogspot.com/2005/05/fantoches.html

Shoes

Então, voltamos ao MVC :slight_smile:

o exemplo acima não está com MVC, poruqe ele pressupõe que você vai mapear um servlet para cada ação.

Se você colocar o código que estaria no servlet em uma Action, ele fará o elo entre o controller e a lógica de negócios, como um filtro.

A teoria é que seu controlador sabe que quando o usuário solicita a URL “/shoes.mvc” ele deve encontrar o objeto que sabe o que fazer com o que o usuário mandar no request, ele acha uma Action que sabe processar o request de um modo que as classes de negócio entendam, transformando em objetos, etc., e passa para elas, recebe a respsota e retorna ao usuário.

As actions são extensões do controller personalizadas por evento solicitado. Você pdoeria, em tese, ter isso no seu controller, mas, caramba, ia ser um SENHOR controle, logo a maioria dos frameworks MVC fazem o controller delegar o processamento especializado a uma ação, que é configurável.

Shoes

Beleza… melhor eu deixar o Controller para um momento futuro… pelo menos por enquanto…

Qto aos objetos… uma pergunta…

Quem faria a conexão com o banco? O DAO? Ou o servlet trabalhando com o DAO?

A url q vc passou eu não consigo acessar daqui… webblogs estão bloqueados no ambiente corporativo… coisa triste…

O Dao. Imagine o seguinte:

Usuario [color=“red”]< view > < negocio > <persistencia >[/color] banco de dados

Entre o servlet e a persistência tem a camada de negócios.

Seu servlet deve passar a requisição rpa camada de negócios e mandar ela se virar, ela sim vais aber quando e o que persistir, pro Servlet os dados são SEMPRE persistidos automaticamente, não é problema dele saber como ou quando conectar com o banco :wink:

[quote=“dac”]
A url q vc passou eu não consigo acessar daqui… webblogs estão bloqueados no ambiente corporativo… coisa triste…[/quote]

Uhm… então eu não sou o único trabalhando no feriadão…?

Feriadão? Oq é isso? Esse mundo da informática…

Ok… uma coisa me imcomoda… eu tenho minha classe de conexão com a base…
E para conectar a base eu tenho q passar como parametros a url, usuario e senha do banco… estes dados estavam em um JSP… em um include pra ser mais exato… horrível… como não é uma boa prática resolvi deixar no <context-param> do web.xml…
Para q meu servlet nem se incomode com a conexão, eu teria q dar um jeito de recuperar os dados de conexão direto da classe DAO ou da própria classe de conexão… e para isso, essas classes teriam q herdar o HttpServlet… para recuperar pelo getInitParameter…
Li em algum lugar q isso tb não é uma boa prática… herdar o HttpServlet nas minhas classes de aplicação…
E agora?

Escolha, da melhor pra pior:

1 - use uma datasource
2 - Crie um arquivo de configurações properties

10 - Crie um singleton para gerenciar sua confiugração acessível por todas as camadas

Legal… estou montando uma estrutura usando um datasource em um JNDI… adaptei a classe de conexão e está funcionando bem… mas ainda estamos caminhando…

Paralelo a isso… surgiu uma dúvida… há alguns tópicos atrás… vc comentou para deixar o JSP apenas para exibir o HTML e todo o processamento com o Servlet…
Oq vc considera “processamento”? Tipo… no caso de um formulário HTML q existe consultas com o banco de dados… com alguns selects e options com valores q vem de algumas tabelas… isso seria tratado no JSP certo?

Penso q fica um pouco difícil qualquer alteração no design do HTML estando em um servlet… é uma má prática fazer uns includes de JSPs que seriam o topo e o rodapé por exemplo no servlet?

O que eu entendi:

Quando eu preciso consultar dados no SGBD, eu posso fazer direto no JSP?

Poder pode, dever não deve :slight_smile:

Seu servlet não pode processar isso (no caso, nem ele deveria acessar o banco, mas isso fica pra outro psot, vamos simplificar :wink: ) e colocar em escopo de request para sua JSP?

O Servlet não deve ter lógica de apresentação, ele deve fazer o meio de campo entre o HTML (responsabildiade do JSP) e o seu sistema (camada de negócios, domínio, banco de dados, etc.).

Se não enendi, tenta com outras palavras :stuck_out_tongue:

Shoes

Entendi… era essa mesma a minha dúvida…
Tem algum exemplo prático disso? Em códigos?
Bom… vou dar uma procurada no google…

Achei algo por aqui mesmo…

http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=8332

Fiz uns testes… legal… total independencia do design das regras de negócio… vejo muitas possibilidades aqui…

Esse papo todo me deixou cheio de dúvidas…

Mas beleza…

Vou postar em outros fóruns do Portal Java…

Já fica longe de ser Dúvidas MVC…

Valeus!!!