padrao (MVC)

Fala galera...

seguinte....qto à estrutura a ser usada em um projeto...

quais seriam as vantagens e desvantagens (se houverem) de se usar o padrao MVC (talvez com o Velocity como View) ou usar apenas JSP + JavaBeans??

existe alguma diferenca de performance entre as estruturas acima??

sei q sem duvida a melhor de se dar manutencao eh o MVC....mas quais outras vantagens, alem dessa??
o Controller do MVC nao fica mto sobrecarregado recebendo todas as requisicoes??

aguardo a opiniao de todos...

valew

com certeza estrutura MCV2 é mais lenta...
mas quando voce for dar suporte numa estrura MVC1 (jsp - beans)
num projeto grande, vai se arrepender de nao usar MVC2

jsp é compilado pelo conteiner e vira uma servlet... um controller em MVC É UM SERVLET, entao "ficar sobrecarregado" é a mesma coisa em jsp e em controller (action)

soh p/ exclarecer..

MVC1 eh jsp+ beans
MVC2 eh usando Controller...

certo??

outra coisa....as vantagens param na manutencao??

MVC1 é a estruta JSP + Beans e acabo

MVC2 é o que o struts faz, utilizando actions (controller), model, e view (jsp)

quer dizer, view so mostra as coisas na tela (nunca, mas nunca se conecta com o banco "model" )

controller sao os actions que pega as coisas no banco e passa pro view,
pode conter regras de negocio,
quer dizer, faz o que o nome diz... "controle"

model é a parte de controla o banco, pode usar JDO, Hibernate nesse caso ... é formado basicamente por beans que representam as tabelas do banco, pode conter regras de negocio aqui (eu particularmente prefiro colocar no model do que no controller)

foi o q eu pensei mesmo Max...

o view apenas mostrando os dados.....poderia usar o velocity aqui....
o controller q recebe os actions e chama os beans p/ efetuar acoes no banco....
o model contendo acoes do banco e a regra de negocio....

assim o controller ficaria "mais leve" apenas recebendo requisicoes e passando p/ as respectivas classes....

e na hora de devolver dados p/ view?? o controller faz ou os beans podem fazer isso??

Não é só vantagem de manutenção. Imagine vc ter suas regras de negócio misturadas com as instruções de acesso à dados tudo isso no meio de html e código server-side (jsp)... fica lindo!!!

nao caso do struts voce pode ter um bean de formulario para controlar os dados do mesmo...

fora isso, normalmente se coloca os dados no request da pagina e manda pro jsp, no jsp voce recupera esses dados

eu particularmente gosto de colocar tudo em bens fica mais facil de recuperar

exemplo: tenho uma pagina que mostra imagens de produto (uma loja virtual por exemplo) eu faço um bean com set e get pra imagem, descricao, preços e demais informacoes... consulto no banco,
no controller eu pego o resultado do model e populo esse bean, e coloco ele no request da pagina...

e no jsp eu recupero esse bean e mostro na tela... fina facil, bonito e organizado

obs.: se necessário retornar um Array desses beans, crio uma Colletion... normalmente da interface Set ou List, e no jsp recupero o iterator dessa Collection e monto o html

simples

colocando as regras no bean sua aplicação fica livre de "ambiente"
imagine, seu cliente disse pra vc, que agora ele quer tudo em java Desktop

o model e as regras de negocio (que sao os mais complicados) nao mudam... voce reaproveita tudo ... so tem que alterar o view e o controller

minha unica duvida quando ao medole MVC sao os views... por exemplo, uma taglib pode conectar-se ao banco? ou isso é errado?

Até é possivel se conecar no banco via tag-libraries (eu particularmente nao gosto), se não me engano, a jakarta tem tags para esta finalidade. Dizem que dependendo do tamanho do projeto (se for muito pequeno) não vale a pena montar toda a estrutura requerida pelo MVC. Assim dá pra usar tudo com custom tags, sem usar scriptlets.

[]s, Welington B. Souza

controller sao os actions que pega as coisas no banco e passa pro view,
pode conter regras de negocio,
quer dizer, faz o que o nome diz... "controle"

As Actions no Struts não SÃO o controller (e existe até mesmo discussão se elas fazem parte do Controller ou não). O Controller é o servlet "coração" Struts, juntamente com o RequestProcessor. A função do Cotroller é decidir quem (das Actions) deverá processar o comando solicitado pelo usuário.

As Actions implementam o pattern Command (comando) e, junto com o Controller, implementam o Command-Controller.

As Actions não deveriam conter regra de negócio: elas funcionam como uma ponte entre o Controller e o Model. Se a action conter regra de negócio, então sua estrutura MVC é invalidada, pois caso se utilize Swing sem acesso a servidor web, por exemplo, vc tem que reescrever suas regras de negócio novamente em um outro componente, já que as Action do Struts não estarão mais disponíveis.

minha unica duvida quando ao medole MVC sao os views... por exemplo, uma taglib pode conectar-se ao banco? ou isso é errado?

Se você cria uma taglib que acessa o banco ocorre algumas coisas indesejáveis:
1 - Você está fazendo a view acessar direto o banco, sem passar pelas regras de negócio do Model.
2 - Você fica preso ao banco de dados. Se depois seu repositório mudar para XML, por exemplo, sua tag tem que ser reescrita.

JavaBaby Membro desde: 07/01/2003 02:31:30 Mensagens: 96 Offline

karai... num entendi nada dissuu hehehehe

Aprendi agora na faculdade A Usar agora o modelo de camada mais deixando tudo no java, e na fachada vc implementa o singloton (acho q é assim de se escreve) e para apresentar o usuario usar JSP, pensei q sabia alguma coisa de java!!!

Emanuel F Silva ...... e-MaNé

Java Ninja Membro desde: 18/01/2008 10:24:27 Mensagens: 262 Offline

Galera, reacendendo esse post e baseado no comentario da galera, o pessoal falou pra inserir a regra de negocio no bean, mais quando eu quero usar um mesmo bean pra varias telas por exemplo, que contem regras diferente, eai?

Thread.start() Membro desde: 25/07/2006 20:56:52 Mensagens: 40 Offline

mais quando eu quero usar um mesmo bean

várias telas por exemplo, que contem regras diferentes

Mas se são regras (negócios?) diferentes porque não criar beans diferentes?
Entretanto eu já vi utilizaram um mesmo bean (um DTO) com TODOS os atributos mas, não acho que seja uma maneira elegante de se resolver esse conflito.

[]'s

Notícias, artigos e o maior fórum brasileiro sobre Java