Dúvidas MVC

33 respostas
D

Olá pessoal…

Gostaria de saber a opnião de vocês sobre a estrutura de algumas classes da minha aplicação em ambiente web…

Sou iniciante no MVC… tenho lido alguns materiais… e gostaria de adequar minha aplicação nesta estrutura…

  • Tenho duas classes de conexão com a base de dados, pois tenho dois servidores distintos… estas classes apenas conectam com as bases, e executam querys… por exemplo…
  • Tenho uma classe para recuperar os comandos SQL que estão armazenados em arquivos XML… estes comandos são recuperados através de parametros… por exemplo, para recuperar os dados de um usuario onde seu código é “1” eu codifico:

cmdsql.setOperacao("seleciona_usuario"); cmdsql.setParametro("@usuario", "1"); String sql = cmdsql.getComando();

  • Tenho classes para armazenar meus objetos… apenas com atributos, gets e sets… por exemplo

Usuario usuario = new Usuario(); usuario.setNome( rs.getString("nome") );

  • Estou criando uma classe para controlar operações com métodos para inserir, alterar, deletar recuperar os dados…

Quanto ao View… estou planejando exibir os dados no browser utilizando taglib + jstl para manter o jsp com menos scriplets possíveis…

Estou no caminho certo? Estou meio perdido no conceito do Controller… seria isso mesmo? Meu controller precisa necessáriamente ser um Servlet?
Misturei as bolas galera? Até então eu achava que MVC tinha o mesmo conceito de 3 camadas… li em alguns lugares que o MVC está tudo na camada de apresentação… é isso mesmo? Na internet tem muita gente se contradizendo… alguém recomenda um bom livro em português sobre MVC com codificações em java? Tudo q li sobre MVC é muito vago… só conceitos e teoria… muito pouca coisa de códigos…

Valeu se alguem puder acender uma luz no fim desse obscuro e temível túnel…

33 Respostas

G

Não é que exista o MVC com tudo na camada de apresentação, é que muitas pessoas por desconhecer o MCV, acabam implementando tudo somente em uma camada(View)…tornando a manutenabilidade da aplicação muito difícil…

:wink:

P

Olá,

Ok, vamos ver…

[quote=“dac”]

  • Tenho duas classes de conexão com a base de dados, pois tenho dois servidores distintos… estas classes apenas conectam com as bases, e executam querys… por exemplo…

[quote]

E retornam o que para quem? QUem as chama?

Isso é elgal, mas quem chama esa classe?

Isso é péssimo. Criar objetos “burros” como esse é programação procedural.

Isso não é um controller, é um Façade.

Me diz uma coisa: esse me´todo getUsuario, por exemplo, vai na classe de conexão, faz a query, pega o resutlset resultante e cria um objeto Usuario baseado nele?

Não e não. Seu cotnroller pode ser uma classe Java normal, um POJO.

MVC e 3 camadas são coisas diferentes.

Programar em camadas é definir responsabilidades distintas e agrupar objetos por elas. MVC é uma política de tratar eventos externos ao sistema. É meio difícil a princípio, mas continue lendo :wink:

S

Aproveitando …

que materiais que vcs indicam para estudar MVC … materiais dos bons!!! … eh que quero aprender a programar que nem gente grande!!!

Abraços,

M

“Spirulita”:
Aproveitando …

que materiais que vcs indicam para estudar MVC … materiais dos bons!!! … eh que quero aprender a programar que nem gente grande!!!

Abraços,

Google? hehehehe :roll: … e o próprio fórum do Portal Java

S

Bem …

agradeço a ajuda … mas eu queria um material mais especifico … sabe como que é né … recomendado por quem conhece!!!

Abraços,

M

“Spirulita”:
sabe como que é né … recomendado por quem conhece!!!

owned… :ysad:

G

blueprints MVC

:wink:

S

“matheus”:
“Spirulita”:
sabe como que é né … recomendado por quem conhece!!!

owned… :ysad:

Sorry … me expressei mal … eh que no google eu fico meio perdida , principalmente quando naum sei o assunto … entaum queria que vcs fossem mais especificos …

Milhoes de desculpas Matheus!!! Naum sei nem o que dizer … :roll:

Abraços,

D

“Spirulita”:
“matheus”:
“Spirulita”:
sabe como que é né … recomendado por quem conhece!!!

owned… :ysad:

Sorry … me expressei mal … eh que no google eu fico meio perdida , principalmente quando naum sei o assunto … entaum queria que vcs fossem mais especificos …

Milhoes de desculpas Matheus!!! Naum sei nem o que dizer … :roll:

Abraços,

hummmmmmm :roll:

M

“diogoacl”:
“Spirulita”:
“matheus”:
“Spirulita”:
sabe como que é né … recomendado por quem conhece!!!

owned… :ysad:

Sorry … me expressei mal … eh que no google eu fico meio perdida , principalmente quando naum sei o assunto … entaum queria que vcs fossem mais especificos …

Milhoes de desculpas Matheus!!! Naum sei nem o que dizer … :roll:

Abraços,

hummmmmmm :roll:

heheheh… ok ok… bem, aqui tem uma boa referencia:

http://java.sun.com/blueprints/patterns/MVC-detailed.html

G

shoes, porque vc diz que um Bean é um objeto burro ??

:wink:

M

shoes, porque vc diz que um Bean é um objeto burro ??

:wink:

bem, é q no estado natural da arte OO um objeto tem q ter estados e comportamento hehehes tipo… q comportamento tem um objeto dotado somente de setters e getters? ele deve ser autocontido… qnd tu recupera um dado desse objeto, ele tem q vir pronto pra ser usado, e não antes ter q passar por algum processamento adicional pra deixar como tu quer… deve ser um componente… ahmmm… ta, chega, são 23:30h da noite e eu to loco de sono e cansado, to indo pra cama hehhehe :lol:

P

Oi,

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

D

Caras… estou assustado… eu estava em um túnel escuro… aí pensei ter visto uma luz… mas agora acho q não foi a luz q eu procurava… estou assustado…

Bom… vamos lá…

Estou montando todas essas classes ainda… por enquanto quem chama todas elas é o JSP… mas estou planejando fazer o seguinte:

  1. No jsp, taglibs que executarão minhas tarefas… que serão executadas em uma classe e tal… por exemplo…
  2. Essa classe do tld iria chamar o tal do Façade… instanciar os “objetos burros”… e aplicar nos beans com as regras de negócio…
  3. quem chama as classes q retorna os comandos sql e o de conexão seria o tal do Façade… essa outra classe que apenas vai fazer a conexão com o banco e popular o objeto com os dados da base de dados…

Então… quem iria criar esses objetos de conexão e do sql seria o tal do “Façade”…

Façade? Então não é o Controller… bom… eu li esse outro tópico… e pelo q eu vi… esse Façade não é a mesma coisa q um ADO? Imagino essa classe como uma camada para efetuar as operações com a base de dados…
E é isso mesmo… o cara “Façade” cria a classe do getComando, pega a instrução sql, cria a conexão com o banco, passa o sql, pega um recordset e cria um objeto Usuario com os dados do banco… e retorna pra quem o chamou… que seria a classe que vai trabalhar com a taglib…

Bom agora já não sei… como assim objeto burro? Tipo… seria melhor q meu próprio objeto “Usuario” carregasse os dados do banco? Sem precisar desse outro objeto… o “Façade”? Q até então eu achava q era o Controller… q talvez seja o “ADO”… Vish… estou confuso…
Mas claro… se meu objeto Usuario precisar de outro método vou colocar nele… mas apenas estava pensando em deixar as operações com o banco fora desses objetos… isso é péssimo mesmo? Seria mesmo um objeto burro?

Valeu pela ajuda!

G

esse Façade não é a mesma coisa q um ADO? Imagino essa classe como uma camada para efetuar as operações com a base de dados…

ADO ou DAO ???

:wink:

D

:oops: Ops… perdão…
DAO…

G

“dac”:
:oops: Ops… perdão…
DAO…

certo amigo, sem probelma…

bom… pelo que eu sei um Façade representa uma fachada que encapsula determinados processos, ou seja, reduz a complexidade do sistema…

e um DAO é um componente que forneçe uma relação entre a aplicação e um ou mais dispositivos de armazenamento de dados, como uma base de dados ou um arquivo…

se falei alguma besteira… me corrijam !!!

:wink:

P

Oi,

Calma e não se culpe, programação OO aidna não é muito difundida, muito menos na comundiade Java.

Sua JSP executa processamneto? Esqueça isso. JSP e oturas tecnologias para gerar documentos HTML (ou XML, ou qualquer coisa) dinâmicos não devem realizar processamento mairo que criar HTML dinâmico. Nada que envolva banco de dados.

Tenha semrpe um Servlet (ou uma action, sei lá) que despacha a solicitação para sua camada de negócios, pega a respsota que interessa á JSP e a coloca em algum escopo que essa possa alcançar (preferencialmente request), e a JSP apenas pega essa respsota lá, formata e exibe :wink:

Seu Façade não está fazendo coisas demais?

O seu Façade deveria apenas receber uma chamada e passar os dados desta para as classes de negócio responsáveis. Façades não devem processar regras de negócio muito menos entrar em contato direto com JDBC.

Para JDBC em projetos simples, você pdoe usar um DAO, que não tem nada de Façade, dê uma olhada nos padrões da Sun.

Um “objeto burro” é o que não tem comportamento, só estado. Na verdade é indistinguível de uma struct ou um register de linguagens de programação procedural. Seus objetos não dvem expôr o estado apra outros objetos, e as regras de negócio que são responsabilidades de um objeto devem estar implementadas neste, não em Façades, Commands, Actions ou qualquer otura coisa.

Para a persistência, existem diversas alternativas, mas o objeto não deveria em Java contactar o SGBD diretamente, use um DAO ou algo do tipo.

Shoes

D

Ok… acredito q estou começando a sacar…

Bom… então o ideal seria…
Para o exemplo de um login…

O diagrama abaixo estaria legal?

Tipo… qual seria o comportamento ideal do servlet? Todo processamento estaria nele certo?
Quanto ao DAO… quem chamaria? O objeto Usuario? Para q ele não seja mais “burro”?

P

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.

“dac”:

Quanto ao DAO… quem chamaria? O objeto Usuario? Para q ele não seja mais “burro”?

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

D

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…

D

Mas ficou uma dúvida quanto ao MVC ainda…

Nestes exemplos… quem seria o Controlador?

P

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

P

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

D

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…

P

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:

“dac”:

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

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

D

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?

P

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

D

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?

P

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

D

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

D

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…

D

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!!!

Criado 25 de maio de 2005
Ultima resposta 9 de jun. de 2005
Respostas 33
Participantes 6