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:
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…
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…
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
[quote=“matheus”][quote=“Spirulita”]sabe como que é né … recomendado por quem conhece!!!
[/quote]
owned… :ysad:[/quote]
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:
[quote=“Spirulita”][quote=“matheus”][quote=“Spirulita”]sabe como que é né … recomendado por quem conhece!!!
[/quote]
owned… :ysad:[/quote]
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:
[quote=“diogoacl”][quote=“Spirulita”][quote=“matheus”][quote=“Spirulita”]sabe como que é né … recomendado por quem conhece!!!
[/quote]
owned… :ysad:[/quote]
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:
shoes, porque vc diz que um Bean é um objeto burro ??
[/quote]
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:
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:
No jsp, taglibs que executarão minhas tarefas… que serão executadas em uma classe e tal… por exemplo…
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…
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?
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…
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
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.
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”?
