[NÃO RESOLVIDO] Aplicações JSF com MVC

xhtml —> ManagedBean —> Controladores

Ficaria mais ou menos assim. [=

jakefrog:

xhtml —> ManagedBean —> Controladores

Ficaria mais ou menos assim. [=

jakefrog, não entendi…

Suas páginas vão chamar o ManagedBeans. Os ManagesBeans irão chamar seus controladores.

hm…no meu ponto de vista, no JSF o ManagedBean assume o papel de controller, e dentro dele o modelo é manipulado. Não concorda jakefrog?

Cara, eu vejo isso como questão de gosto e não de
regra.
Eu gosto de ter uma camada a mais pelos seguintes motivos:

1. você não vai misturar regra de negócio no mb com regras de view.
2. se você precisar mudar a view para struts por exemplo, não terá que mudar nada no controller.

É questão de gosto. Gosto de manter o sistema desacoplado.

Cara, eu vejo isso como questão de gosto e não de
regra.
Eu gosto de ter uma camada a mais pelos seguintes motivos:

1. você não vai misturar regra de negócio no mb com regras de view.
2. se você precisar mudar a view para struts por exemplo, não terá que mudar nada no controller.

É questão de gosto. Gosto de manter o sistema desacoplado.

Hm, sim, concordo com essa abordagem. Mas no meu entendimento o controller é o cara que recebe as solicitações da view; daí pra trás é tudo modelo. Entao uma regra de negocio nao ficaria no managedbean, e sim em uma camada separada (mas que faz parte do modelo, do domínio em questão).

alias:

Hm, sim, concordo com essa abordagem. Mas no meu entendimento o controller é o cara que recebe as solicitações da view; daí pra trás é tudo modelo. Entao uma regra de negocio nao ficaria no managedbean, e sim em uma camada separada (mas que faz parte do modelo, do domínio em questão).

isso aí. To contigo então.

Eu utilizo da forma em anexo, separado em pacote.

Paginas.xhtml são as view
ManagedBean e o Controller
Regra negocio, DAOs são a Model

A View interage Controller. Controller interage com a Model.
Sendo que nenhuma das camadas sabe como outra é implementada, ficando definido cada responsabilidade.

Você pode mudar o layout na view que a controller não vai ser afetada. Você pode mudar de JDBC para Hibernate sem precisar mudar a controller…

2012/7/27/6116a6c5bb42a8c9e2d5a688aee0a722_128477.png_315×528 21 KB

Cara , pra mim o MVC no JSF já é algo “embutido”, ou seja, o proprio framework internamente implementa o padrão MVC…

No caso do JSF o controlador seria o facesServlet

depois coloco o link aqui que consolida o que falei.

erickfm8:

Cara , pra mim o MVC no jsf já é algo “embutido”, ou seja, o proprio framework internamente trabalha com MVC…

e no caso o controlador sera o facesServlet,…

depois coloco o link aqui que consolida o que falei

Vou querer olhar no seu link oq é defendido. [=

segue…

referencia http://www.ibm.com/developerworks/web/library/wa-dsgnpatjsf/index.html
Outro ponto a resaltar é que o MVC é usado na camada de apresentação… tem muitas pessoas que confunde o padrão MVC com as separações entre as camadas da aplicação

veja bem … não querro que isso se torne uma discução… estamos aqui para refinar nossos conhecimentos

Utilizando o ManagedBean com regra de negócio oq ele diz se contradiz:

Similarly, if you need to change a model, the view layer remains largely unaffected.

Bem, é gosto e eu vou ficar discutindo ñ. [=

FacesServlet seria o FrontController

Utilizo uma abordagem xhtml>ManagedBean>DAO,algo como:

class ClienteController{
      @Resource
      ClienteDAO dao;
      Cliente cliente;

    public void salvar(){
      dao.salvar(cliente);
}

}

http://www.oracle.com/technetwork/topics/index-090910.html

aqui ele deixa claro que o FacesServlet é o controle.

Pessoal leia este post, esclarece muitas coisas

http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/

Pessoal, resumindo as sugestões que vocês deram…
Para ter o controlador ligado diretamente a camada view, como faço para instanciá-lo ? Utilizando JSF…

erickfm8:

JavaServer Faces’ Implementation of MVC

One of the key advantages of JSF is that it is both a Java Web user-interface standard as well as a framework that firmly follows the Model-View-Controller(MVC) design pattern. This makes JSF applications much more manageable because the user-interface code ( View) is cleanly separated from the application data and logic ( Model). To prepare the JSF context, which provides application data access to the pages, and to guard against unauthorized or improper access of the pages, all user interactions with the application are handled by a front-end “Faces” servlet ( Controller).

http://www.oracle.com/technetwork/topics/index-090910.html

aqui ele deixa claro que o FacesServlet é o controle.

Pessoal leia este post, esclarece muitas coisas

http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/

Excelente post esse http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/

Eu já conhecia a diferença entre MVC e camadas, mas este esclareceu melhor!

Conforme as referencias expostas aqui. No caso do JSF o controlador é implementado pelo framework ao meu ver, ou seja o proprio JSF instancia para você.

erickfm8:

Pessoal, resumindo as sugestões que vocês deram…
Para ter o controlador ligado diretamente a camada view, como faço para instanciá-lo ? Utilizando JSF…

Conforme as referencias expostas aqui. No caso do JSF o controlador é implementado pelo framework ao meu ver, ou seja o proprio JSF instancia para você.

Quando faço referência ao controlador dentro de uma página jsp é retornada a seguinte mensagem:

javax.servlet.ServletException: Target Unreachable, identifier ‘ClasseControle’ resolved to null

Mais para que vc quer fazer referencia ao FacesServlet?

Mas essa classe é um controlador normal…
Ou seja, em qualquer view que eu fizer referência a um controlador vai me retornar nulo.
Entendeu ?

cara vc não precisar instaciar o FacesServlet
pois o JSF já encarrega de instaciar e fazer o trabalho.
leia o post do sergio que eu postei

adi_silva, eu uso meu padrao mvc exatamente igual ao que vc postou nessa print.

até os nomes, RN e a sequencia de todos esses arquivos no mesmo pacote está identico. xD

maaarkin:

adi_silva, eu uso meu padrao mvc exatamente igual ao que vc postou nessa print.

até os nomes, RN e a sequencia de todos esses arquivos no mesmo pacote está identico. xD

RSRS

Então maarkin, ano passado comprei um livro de java, muito bom por sinal. Se chama “PROGRAMANDO JAVA PARA WEB” li ele, apartir dai começei a implementar nos meus projetos(somente para estudo) da mesma forma…

kkkkkkkkk

eu tambem comprei esse livro, eu uso meu padrao exatamente igual ao do livro… depois dele ficou muito mais facil entender as camadas.

Cara, eu vejo isso como questão de gosto e não de
regra.
Eu gosto de ter uma camada a mais pelos seguintes motivos:

1. você não vai misturar regra de negócio no mb com regras de view.
2. se você precisar mudar a view para struts por exemplo, não terá que mudar nada no controller.

É questão de gosto. Gosto de manter o sistema desacoplado.

Não é uma questão de gosto. É uma questão tecnica chamada Separação de Responsabilidade (Separation of Concerns , SoC).

O ManagedBean é de fato o controlador do JSF que embute o MVC no seu design como alguém já falou. Tentar adicionar MVC em cima disso é simplesmente não saber o que está fazendo e precisar estudar mais JSF e MVC. Contudo, nada impede o controlador de chamar outros objetos. Aliás, pelo MVC ele teria que controlar o modelo. Mas quem é o modelo ? Os beans que são colocados no request para serem renderizados pelos componentes ? podemos dizer que sim. Contudo de onde vieram esses dados ? Não será esse lugar o modelo ?

O controlador é livre para compor a chamada a outros objetos, contudo, a bem da simplicidade e do SoC é bom que ele chame apenas um outro tipo de objeto.
Este objeto é normalmente um service façade que faz a ponte entre a camada de apresentação e a camada de dominio, mas existe um outro padrão que é usado por alguns - que é o seu caso aqui : BusinessDelegate

O BusinessDelegate é um objeto da camada de dominio que é “enviado” para a camada de apresentação como um embaixador de um pais é enviado para outro. O papel dele é traduzir as abstrações da camada de apresentação para a camada de dominio. Então o controler só conhece de UI - como deve ser e quem conhece o dominio é o BusinessDelegate.

A ideia é boa, quando bem implementado e ajuda a isolar a camada de apresentação. Os sistemas hoje são muito desenhados como acessadores de banco de dados e pouco isolados. Pegue um sistema que vc conhece e avalie se é possivel mudar a camada de apresentação sem mudar a camada de dominio. Muito provavelmente não é.

Será mesmo que consegue isto ou esse objeto está tão amarrado ao fluxo do JSF que nem isso seria possivel ? Não será que vc está colocando uma camada a mais sem ter realmente nenhuma vantagem ? Quer descobrir de fato ? experimente portar seu sistema para struts e nos diga se foi tão simples assim.

Desacoplar é uma coisa, colocar mais camadas é outra.