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

Assuntos Gerais
#1

Boa noite pessoal,

Estou estudando JSF e fazendo a revisão de uma aplicação proposta por um material da comunidade.

Gostaria de levantar esta questão (título) porque não encontrei a real localização dentro do modelo MVC para uma classe/objeto do tipo Managed Bean.

O Java Server Faces tem como proposta aproximar a web de uma plataforma desktop, tornando assim, quase imperceptível para o usuário suas requisições sobre objetos persistentes.

Nota: Alguém já programou algum software desktop aplicando o modelo MVC?
Demoro pra responder ein! rs.

Pois bem. Então como levar a web a este patamar e manter o MVC como costumeiramente está.

Exemplificando:

Fluxo no Modelo MVC convencional:

[ loop ]... render view :: submit form view :: browser process :: server process [ request :: response ] :: switch view for :: render view ... [ / loop ]

Um dos tipos de fluxos do Modelo classico Desktop/JSF:

[ static ]... render view :: ajax interactive action :: server process [ request :: response ] :: stop [ / static ]


CRUD Modelo desktop

O poder da View (página renderizada) utilizando o JSF vai muito além do que comumente encontra-se em convencionais aplicações web.
Basicamente você pode fazer tudo a partir da view (CreateReadUpdateOrDelete).
Sim, a view tem o poder, mas não se enganem, por traz de toda jsf view tem sempre uma boa e nova Managed Bean.

E quem seria a Managed Bean no modelo MVC ?

Seria uma model ?
Uma Bean é uma model, pois representa uma entidade (tabela).
Uma DAO (http://pt.wikipedia.org/wiki/Data_Access_Object) é uma model de interação com a base.
Mas e a Managed Bean! Quem és tu?

Seria uma view ?
A primeira pergunta para responder a questão é: A Managed Bean está alocada no cliente ou no servidor?
Resposta de atrapalhar: No servidor. Mas solicitada em tempo de execução (Real Time) por blocos EL (Expression Language) alocados na VIEW.

Seria a Controller ?
Hunn, é com quem, na minha humilde opnião, mais se parece no contexto exposto pois exerce funções similares a de uma Controller, tais como:
Resgate e validação de objetos e atributos da view (BEANs).
Funções para chamadas de objetos manipuladores de instâncias persistentes (DAOs).
Retorna a view conforme o processo (successOrfailure).

Este ultimo processo, mapeamento de views, é dado no JSF1 a partir de um arquivo de configuração, o faces-config.xml, este ultimo, é também, responsável por armazenar o escopo de cada Managed Bean de um sistema (managed-bean-scope).
No JSF2 é possivel mapear a url e as Managed’s Bean’s via annotations sobre as mesmas. Algo parecido com o que aconteceu com o Struts.

Bom é isso, estou levantando a discussão sobre quem és tu Managed Bean no contexto MVC?
Outra nota que também vale a pena levantar, aproveitando o gancho é: Seria realmente mais produtivo e organizado efetuar todas as quatro operações (CRUD) sobre uma mesma interface web, tal qual aplicativos desktop?

Outra questão é: Para que usar uma ferrari para fazer o serviço de um ol bolinha?

Eu prefiro uma Ferrari mas …

Abçs.
Jsign

#2

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

#3

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

Abraços,
Jsign

#4

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.

#5

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

#6

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

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

#7

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

#8

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…

#9

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

#10

muito obrigado :] compreendi perfeitamente! :smiley:

#11

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

#12

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?

#13

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

#14

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)

#15

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”.

#16

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

#17

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.

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

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"; 
}

}[/code]
http://docs.oracle.com/cd/E13224_01/wlw/docs103/guide/webapplications/jsf/jsf-app-tutorial/2.ManagedBeans.html

#18

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.

#19

[quote=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”.[/quote]
Com base nesta explicação o modelo proposto pelo everton.battini está incorreto, pois ele tratou o ManagedBean como controle(ligar a view com o model) e inseriu junto as regras de negócio.

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?

#20

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).