Managend Bean do JSF + Controle + MVC

andersonlandim:

Tenho lido muito no guj e em outros sites. Vários tópicos muito bons aqui mesmo, mas…

Ficou um pouco confuso para mim a questão do Controle implementado no JSF. Sei que o o próprio JSF implementa uma parte do controle para mim. Então minha dúvida é a seguinte:

• Eu tenho um MBean com os componentes da view. Esse cara é uma representação da view certo? Pra mim faz parte da view.

• Quando eu clico num botão para cadastrar um usuário por exemplo, quem seria o controle? Eu deveria colocar dentro do Mannaged Bean? Seria correto? Essa é minha dúvida, o Mannaged bean seria um controle também ou eu deveria criar outra classe especializada para isso?

ps: Com relação ao modelo eu não vejo problemas, a minha única dúvida é com relação ao Mannaged Bean e o Controle.! vlw

MB = Controller

Anderson,

pense que o jsf é apenas um cliente para sua aplicação. Se ela fosse desktop? ou qualquer outra tecnologia para o cliente, iria funcionar da maneira que voce está implementando? Uma boa forma de pensar nisso é elaborando os testes antes de implementar (@see TDD), ou seja, fazer o codigo testável, desacoplado da visão.

[]'s

Humberto Lima

humberto.lima:

Anderson,

pense que o jsf é apenas um cliente para sua aplicação. Se ela fosse desktop? ou qualquer outra tecnologia para o cliente, iria funcionar da maneira que voce está implementando? Uma boa forma de pensar nisso é elaborando os testes antes de implementar (@see TDD), ou seja, fazer o codigo testável, desacoplado da visão.

[]'s

Humberto Lima

E ai Humberto , blz;

Cara da forma que eu fiz o modelo sim, eu posso mudar algumas coisas. Com excessão do spring… To usando annotations e hibernate. tbm

Com relação a view ok, mas e o controle? De tudo o que eu li eu cheguei a conclusao de que o controle é muito “intimo” da view… Não sei bem, actions, o mannaged bean. Esse é o maior problema. O CONTROLE… srsrsrrs

Por isso eu pergunto, o MBean deve conter apenas dados vindos da view, ou implementaria uma parte do controle como metodos que respondem a eventos de botoes.

Tipo numa tela de login, o botao logar vai estar ligado ao MB ou a um Controler Bean. Estou confuso…

Cara, tambem achei esquisito isso .

Pelo que eu vi as ações ficam dentro do Mananged Bean, em métodos especificos, ou seja, você pode até chamar classes de outras camadas la dentro, mas a ação é diretamente ligada ao MBean.

No caso eu achei estranho, porque isso de alguma forma quebra um pouco da organização que uma aplicação puramente com MVC Servlets e JSP’s proporcionam.

Pessoal pensem a respeito das responsábilidades de cada componente da GUI.

A View vai ser uma representaçao do seu modelo. A diferença é que ela pode ter varias apresentações do mesmo modelo certo? Pensando dessa forma faz sentido eu ter um único ManagedBean (Modelo) sendo referenciados em várias views diferentes certo?

Quando falamos de Controller do MVC estamos falando de uma classe que direciona os inputs realizados na tela chamando ações do modelo. O Controler trata esses inputs e depois define qual view será chamada de acordo com a resposta do Modelo.

Sendo assim toda View no MVC possui um controller acoplada. Se pensarmos que o JSF faz isso de forma transparente, nesse sentido o MB também poderia ser considerado um “Controller”. Porem não podemos esquecer que estamos falando de uma aplicação WEB e que por trás de tudo ainda existem toda a parafernalha do protocolo HTTP.

Quando você clica em um botão em uma view do JSF, valores da request ainda serão parseados e transformados e atualizados para serem tratados no seu MB.

Anderson,

Quando você aperta um botão em uma aplicação, com JSP/Servlets algum comportamento da aplicação será chamado certo?
No JSF é a mesma coisa, por isso as ações tem que ser implementadas no MB. O ManagedBean carrega estado e comportamento do modelo.

Se você acha que isso de certa forma desorganiza seu modelo, uma coisa que você poderia fazer é separar os MB com comportamentos dos que somente carregam estado, utilizando o recurso de injeção de dependência do Framework.