[ Conceitual ] Quem és tu Managed Bean no MVC?

Exato,pense no Managed Bean como o ‘C’ do MVC

Ótimo raf4ever,
Vou esperar por mais uns dois dias e depois fechar o tópico como solucionado.

Abraços,
Jsign

O controller do JSF é o FacesServlet. O managed bean, em teoria, faz o papel de model. Entretanto, é fato que podemos tratar certos aspectos do fluxo da aplicação no managed bean também.

Boa Tnaires,
Concordo, também, com você.
Na verdade, pra mim, o Managed Bean integra parte das duas camadas facilitando a vida da terceira e tornando esta ultima Super poderoza.
Me assustei ao ver em seu blog esta classe (abaixo).
Confrontaria diretamente o que você disse ter uma Bean estendendo uma Controller.

public class LoginBean extends ControllerBean {
	public LoginBean() {
		// Definindo dois campos para a página de login.
		super.definirParametros("login", "senha");
	}

	public String efetuarLogin() {
		// A classe ApplicationServiceFactory foi apresentada no post anterior.
		Usuario usuario = ApplicationServiceFactory
			// Obtendo o service de usuário, que realizará o login.
			.getUsuarioService()
			// Passando diretamente o Map contendo os campos.
			.efetuarLogin(super.getParametros());

		// Restante do código omitido.
	}
}

Felizmente vejo que sua ControllerBean é na verdade uma classe de administração de ManagedBeans.
Nota: Procuro evitar nomear classes compondo valores que podem atribuir duplo sentido, ou seja: Controller Bean e Controller tem alguma semelhança ?
Se a resposta for não, então não de este nome.
Se a resposta for sim então a ManagedBean é uma Controller.

Mas até ai tudo bem, o susto passou.
Não leve como uma crírtica, na boa mesmo.

Em resumo temos duas opniões a favor de que é uma Controller e uma a favor de que é uma Model.
Vamos esperar mais um pouco.

Abraços
Jsign

É… tudo o que escrevemos na web pode ser usado contra nós…

O que escrevi não está em conformidade com minha opinião. Vou corrigir lá no blog.

Olá pessoal,

Ficou claro que o modelo proposto pelo JSF gera dúvidas quanto a posição da classe ManagedBean no modelo MVC.

Tivemos poucas opiniões, apenas três, mas nem todo mundo quer saber disso não é mesmo.
“Pra que!”.

Acredito que conceituar sobre os frameworks é importante pois serão eles quem ditaram as novas fases da web e acredito que o Java como aplicação web irá crescer ainda muito mais por conta destes (frameworks).

Não vou definir qual o local de fato da ManagedBean no modelo MVC e dar como concluso o artigo.
Nem posso, embora tenha minha opinião semelhante a do raf4ever, perderia o crédito do material disposto até aqui.

O ideal seria gerar uma maior discussão, envolvendo outras pessoas para criar uma definição comum.

Agradeço a vocês tnaires, raf4ever que pontuaram sobre o assunto.
Abraços,
Jsign

rapaiz eu não faço idéia dos conceitos citados, apesar de trabalhar pouco com Java e agora estar direcionado a isso… mas o que ma chamou a atenção nesse tópico foi a consciência que a discussão trouxe… muito bojsignm viu, se as pessoas aceitassem e corrigissem suas opiniões de acordo com o visto aqui… o mundo seria outro viu.

muito nobre a atitude do tnaires e muito boa a colocação do jsign…

Boa noite Celox.
Também admirei a conduta adotada pelo tnaires, parabéns. São poucos que fazem isto.

Vou tentar te ajudar a compreender o tópico.

O modelo MVC (model, view e controller) apóia-se em delegar responsabilidades diferentes em cada camada.

De forma bem simples são elas:

View: ex: uma página HTMl com um form por exemplo.

Model: ex: uma classe que representa uma tabela do seu banco de dados. (pode ser tambem uma classe de interação com a base ex: DAO).

controller: ex: uma servlet que recebe os parametros da view e os manipula, pode vir a transferir estes as propriedades da model(acima) e renderiza uma nova página(view).

Bem! por alto é isto.
Você pode se apoiar melhor aqui: http://pt.wikipedia.org/wiki/MVC

ManagedBean.

Como exemplificado a ManagedBean é uma classe que tem operações/ações sobre o que ela recolhe de dados da view. Estas operações podem ser de persistencia ou não.
A ManagedBean tem opções de validação integrada com a view, metodos de atualização de listagens chamados sem que seja renderizada toda página (por bloco(div)), transita dados dad view para classes de persistencia (hibernate), controla o endereço de retorno entre outras operações.
O diferencial da ManagedBean é que ela deixa a view super poderoza, podendo esta ultima ter um estado similar a de aplicações desktop (por evento).

O artigo tem foco em levantar a real alocação da classe ManagedBean neste modelo (MVC).
Conversando com um professor de uma turma de Arquitetura Java FJ91, este disse que a ManagedBean é realmente uma controller.
Eu acho o mesmo mas respeito a opnião e admiro o comprtamento do tnaires.

Abçs,
Jsign

muito obrigado :] compreendi perfeitamente!

um ano e 4 dias depois…

pelo que entendi, o ManagedBean meio que substitui uma Servlet…

pega dados da view e passa pro model “…transita dados dad view para classes de persistencia (hibernate)…”, e vice versa
pega dados da view, manipula e apenas retorna
controla endereço de retorno

acho que é basicamente pra isso que uma Servlet serve tbm certo?

se é, então ficaria em Controller mesmo

Fiquei confuso depois de ler este tópico, então a ManagedBean seria o controller e o model ao mesmo tempo? Ou eu usaria o Managedbean como controller e criaria outra classe java pro model?

eu usaria o Managedbean como controller e criaria outra classe java pro model

Então, poderia organizar meu projeto assim:

com.Pessoa.bean (Posso colocar as regras de negócio aqui ou devo criar uma classe model (com.Pessoa)?)
com.PessoaController (Aqui seria o ManagedBean?)
com.PessoaDAO (Classe responsável pela persistencia)

eu sei que o tópico é meio antigo, mas já que ressuscitaram e o assunto é bem pertinente…

eu acredito que o managed bean não seja model, view nem tão pouco controller, embora controller seja o que ele esteja mais próximo.

Não é view obviamente, por que ele não se refere a apresentação;
Não é model por que ele não é lugar para se colocar regra de negócio (embora infelizmente seja muito usado dessa forma).
Não é controller por que não é ele quem decide qual view será chamada de acordo com o resultado do model ou qual model seria chamado pela view… no JSF isso fica nos navigation-rules, no faces-config.

eu considero que o managed bean seja um cara que está no meio entre o controller e o model, tipo um Facade. Por exemplo, se temos um Session-Façade para session beans eu acho que poderiamos considerar o managed bean como um “JSF-façade”.

cara, tenho uma estrutura jsf aqui tipo assim

com.modelo.bean.Pessoa (aqui só ficam os atributos da tabela e get set)
com.modelo.dao.PessoaDao (Classe responsável pela persistencia)

com.controle.managedBean.PessoaBean (aqui faz a parte de comunicação do modelo com a view e tem regras)
com.controle.filtro.ControlePhaseListener (aqui tem regras de controle de usuário)

não sei se é a forma mais correta, mas fiz assim

Caros,
Também não sou expert em JSF, na verdade estou começando a estudar à pouco tempo. Mas pelos tutoriais são descritos como negocio ou controladores com regras de negócio.
Na revista JavaMagazine 72 um ManagedBean é ambos, pois as requisições são tratadas por ele, assim como as regras de negócio. Realmente é um pouco confuso.
Acho que o MangedBean nessa visão (JSF) acaba sendo um controller e um modelo ao mesmo tempo. Lembra a arquitetura MVP(Modelo View Presenter), onde o presenter é o ManageBean.
Realmente se fosse para seguir a risca o modelo MVC o manageBean não deveria se comunicar diretamente com a view e o controller ao mesmo tempo.

public String registerUser( ) { //[b] Isso é claramente uma regra de negócio.[/b]

    FacesContext context = FacesContext.getCurrentInstance( ); //[b]Acesso ao controller diretamente, no MVC o modelo não deveria ter esse acesso[/b]
    ExternalContext extContext = context.getExternalContext( ); 
    Map appMap = extContext.getApplicationMap( ); 

    DataStoreBean dataStore = (DataStoreBean)appMap.get(DataStoreBean.DB_NAME); 

    if(dataStore.getUser(userId) != null) { 
      Object[ ] objArr = new Object[ ] { userId }; //[b] O modelo está encaminhando uma view(Mensagem) para o usuário, na real, pelo que sei isso não é trampo do modelo[/b]
      FacesMessage message = MessageFactory.getMessage(context, "userIdExists", objArr); 
      context.addMessage(null, message); 

      return null; 
    } else { 
      dataStore.addUser(this); 

      Object[ ] objArr = new Object[ ] { name }; 
      FacesMessage message = MessageFactory.getMessage(context, "thanksMsg_Registration", objArr); 
      String msg = message.getDetail( ); 
      extContext.getRequestMap( ).put("thanksMsg_Registration", msg); 
      return "success"; 
    } 

}

Antes de mais nada, peco desculpas pela falta de acentos na mensagem a seguir :XD:

Pessoal, creio que esteja havendo uma pequena confusao aqui. Voces estao confundindo model do MVC com domain layer. O model do mvc e o componente que armazena o estado da aplicacao.

Esquecam todo o resto de sua aplicacao (services, DAOs) e pensem apenas no JSF. Quais os componentes que ele tem? Tem as paginas JSF, o FacesServlet e os managed beans (alem do faces-config.xml, claro).

O usuario interage com a pagina e faz requisicoes atraves dela. As requisicoes sao processadas pelo FacesServlet, que dispara uma instancia do ciclo de vida do JSF. A pagina e processada e os dados informados nela sao armazenados no managed bean. Dito isto, quem voces acham que sao o que nessa novela?

• O usuario interage com a pagina. Logo, a pagina e a view.
• O FacesServlet e o controller, pois e ele quem processa a requisicao e toma as decisoes sobre quem vai processa-la, baseando-se no fluxo declarado no faces-config.xml.
• Os dados informados sao copiados para as propriedades declaradas no managed bean. E ele quem esta armazenando o estado, logo ele e o model.

Confundir model do MVC com domain layer (ou business layer) e cair naquele velho mantra daqui do GUJ: camadas e MVC nao sao a mesma coisa. Logo, quando falamos de model do MVC, nao estamos falando necessariamente do lugar onde colocamos nossas regras de negocio.

maior_abandonado:

eu sei que o tópico é meio antigo, mas já que ressuscitaram e o assunto é bem pertinente…

eu acredito que o managed bean não seja model, view nem tão pouco controller, embora controller seja o que ele esteja mais próximo.

Não é view obviamente, por que ele não se refere a apresentação;
Não é model por que ele não é lugar para se colocar regra de negócio (embora infelizmente seja muito usado dessa forma).
Não é controller por que não é ele quem decide qual view será chamada de acordo com o resultado do model ou qual model seria chamado pela view… no JSF isso fica nos navigation-rules, no faces-config.

eu considero que o managed bean seja um cara que está no meio entre o controller e o model, tipo um Facade. Por exemplo, se temos um Session-Façade para session beans eu acho que poderiamos considerar o managed bean como um “JSF-façade”.

Grande explicação tnaires, agora conseguir entender. O controlador está implicito já, não há necessidade de “criar”.
Com relação ao estado do objeto, você disse que ele é salvo no model(ManagedBean), pois bem, devo tratar as regras do negócio dentro do model também, correto?

Nao falo do estado do objeto. Falo do estado da aplicacao. Mas o que seria esse estado? Sao simplesmente as informacoes que a aplicacao deve lidar, que nesse caso sao os dados que o usuario informa e que sao enviados na requisicao.

Geralmente, quando criamos um managed bean para uma pagina, declaramos tambem as propriedades referentes aos campos da pagina. Durante o ciclo de vida da pagina JSF, as informacoes inseridas nesses campos sao copiadas para suas respectivas propriedades (isso, claro, apos passarem pela arvore de componentes e pela validacao, dentre outras coisas). Ou seja, o managed bean esta armazenando as informacoes que a aplicacao lida. Logo, ele e o model.

A partir do managed bean voce pode chamar os servicos da camada de negocios (no managed bean, ainda estamos na camada de apresentacao).

Quanto mais leio sobre isso mais confuso fico. Não tem um exemplo prático usando MB?

Nao falo do estado do objeto. Falo do estado da aplicacao. Mas o que seria esse estado? Sao simplesmente as informacoes que a aplicacao deve lidar, que nesse caso sao os dados que o usuario informa e que sao enviados na requisicao.

Geralmente, quando criamos um managed bean para uma pagina, declaramos tambem as propriedades referentes aos campos da pagina. Durante o ciclo de vida da pagina JSF, as informacoes inseridas nesses campos sao copiadas para suas respectivas propriedades (isso, claro, apos passarem pela arvore de componentes e pela validacao, dentre outras coisas). Ou seja, o managed bean esta armazenando as informacoes que a aplicacao lida. Logo, ele e o model.

A partir do managed bean voce pode chamar os servicos da camada de negocios (no managed bean, ainda estamos na camada de apresentacao).
Então o managedbean é a camada de modelo e apresentação ao mesmo tempo?

tnaires:

A partir do managed bean voce pode chamar os servicos da camada de negocios (no managed bean, ainda estamos na camada de apresentacao).

abraco

Se voce analisar o JSF como ferramenta MVC, o managed bean faz o papel de model. Esqueca todo o resto da aplicacao e pense so no JSF, conforme falei acima.

Por outro lado, suponha que voce construiu sua aplicacao usando JSF. O framework e usado na camada de apresentacao. Entao nao e certo dizer que o managed bean e apresentacao: os managed beans que voce criou compoem a camada de apresentacao, juntamente com todos os artefatos de codigo que colaboram para a construcao da apresentacao.

Nao entendo tanto de UML, mas por que voce iria querer colocar os managed beans num diagrama de classes em primeiro lugar? Qual o valor acrescido a documentacao ao fazer isso?

estou fazendo um trabalho da pós, e esse é um documento de arquitetura de software, e eu preciso colocar os "Pacotes de Design Significativos do Ponto de Vista da Arquitetura"
então preciso mostrar as classes mais importantes que vão estar na minha view, controller e model…
e agora parece que quanto mais pesquiso mais com dúvida eu fico…rsrs primeiramente eu estava pesnando em colocar os mb fazendo parte da view…
mas não sei se eh o mais correto, pois os mb não fazem fronteira com o usuário, ai vi alguns caras falando que o mb seria o controller…
como são os mais importantes, provavelmente eu tenha uma fachada entre o mb e o dao, ai ficaria os xhtml, mb, fachada, model e a persistência… tenho que organizar isso…entende?

Na parte do diagrama nao posso te ajudar (a unica vez que trabalhei com isso foi na universidade mesmo).

Mas se voce quiser ilustrar no seu diagrama que os managed beans compoem a camada de apresentacao, creio que esteja de boa. Note que camada de apresentacao <> view.

Se voce ja tiver alguma parte do diagrama feito, mostra ai

então… tb estava pensando em colocar o mb como view, mas ai o meu controller seria a minha fachada?
esta em anexo como vai ficar a estrutura do meu projeto… como vc classificaria?
Obs: o BaseController é apenas um nome de classe indefinido ainda…rsrs vou descobrir depois que definir oque vai ser os meus mb…

2012/5/2/00d6c52bc55e2fefcec45753d99fd3e6_35038.png_1219×641 19.6 KB

Voce ta criando um pacote so para a aplicacao toda?

Talvez fosse melhor separar os pacotes conforme abaixo (apenas uma sugestao):

• Modelo: aqui voce coloca apenas as classes que compoem o modelo de dominio da aplicacao;
• Infraestrutura: neste vao apenas as classes que cuidam de coisas de infraestrutura, como as classes de persistencia;
• Apresentacao: aqui voce poe as classes que compoem a camada de apresentacao - os managed beans vao aqui.

Depois voce pode fazer um diagrama de pacotes para ilustrar como cada um desses pacotes se relaciona entre si.

então… só para finalizar…eu ja estava esquecendo de postar o resultado final…
eu não deixei em apenas um pacote… esta separado em pages, mBean,entities e dao
da uma olhada nos anexos para ver como ficou…
na verdade esses são os pacotes mais significativos, pode ser que depois eu crie mais alguma coisa… mas a princípio fica assim.

2012/5/10/150e7da97c25cf92c49d730652929152_35038.png_1219×666 15.2 KB

Amigos para acabar com a discussão segue conceito disponível no material oficial da oracle sobre JSF.

Rsrsrsr, agora matou a pau!

De qualquer maneira, sempre vale a pena referenciar este post antológico no blog do sergiotaborda: