Só para constar, essa discussão está muito interessante :idea:
Sobre o assunto “Managed Beans são controllers ou model” a resposta é simples: eles podem ser os dois.
Primeiro vejamos o Faces Servlet: A referência que foi passada (documento da IBM) diz que ele é um Front Controller. Embora relacionado, não é a mesma coisa que Controller. O Front Controller (que é um pattern à parte) é um cara que recebe todas as requisições, faz alguns tratamentos que julgar adequado (depende do framework, por exemplo encapsular os parametros de requisição em um objeto específico, instanciar outros objetos auxiliares, etc) e depois encaminha para que outro - o controller propriamente dito - termine o serviço. Ele não faz o trabalho de Controller sozinho, é apenas um auxílio!
E voltando aos Managed Beans: Eles podem assumir o papel de Controller - quando são chamados para lidar com as requisições, manipular componentes da página e fornecer o outcome para navegação, mas também podem ser o Model - afinal, um detalhe que está passando despercebido nessa discussão é que qualquer objeto pode ser um MB, inclusive objetos de regra de negócio e entidades do sistema!
Só um adendo aqui: Eu disse que o objeto (ManagedBean, Struts Action, etc) que trata a requisição depois do FrontController é o controller, mas isso foi por minha conta mesmo… o pattern não diz isso. Na verdade os dois juntos (Front Controller e “meu controller”) é que formam o Controller, meu objeto seria mais uma espécie de Command.
Mas continuo achando que na prática ele é o Controller!
managed beans como modelo acoplam demais o modelo com o controle… isso por que ai depois para separar esse modelo depois e colocar em um outro controle em um outro framework mvc (o struts) você não vai mais conseguir… na minha opinião, o modelo tem que ficar fora do managed bean e este deve ser invocado pelo managed bean, ou melhor, injetado, mas de qualquer forma deve ficar separado, se ficar no managed bean quebra uma das coisas mais básicas do MVC…
Entendo a relação FacesServlet(controller) e ManagerBean como uma relação de delegação, ou seja, o ManagerBean é um ponto para se refinar situações do controle, uma dessas situações pode ser chamar o modelo. Isto esta muito relacionado com modo o qual o framework foi implementado. Pode-se até colocar situações do modelo (neste contexto vejo modelo como relativo ao negócio) dentro do ManagerBean, mas não acho uma boa alternativa, pois situações de negocio não devem ter forte dependencia de tecnologias(JSF). Quanto mais plano melhor. Mas concordo que o tema é sempre polêmico. rsrsr.
Pessoal, estou iniciando em Java, venho de DOT NET…são muitas siglas, muitos frameworks, muitas tecnologias, enfim…rs…
Durante meus estudos me veio uma dúvida, aí pesquisei e achei esse tópico que creio que tem a ver:
Se EJB necessita do container EJB, está atrelado a WEB, certo?
Então, meio que perde o sentido trabalhar com MVC, já que meu sistema só poderá ser WEB.
Não poderei pegar a camada Model e usá-la em um desktop ou mobile, por exemplo.
É isso mesmo turma? estou pensando certo?
Entao EJB é furada? …rs
Outro assunto, tem vários exemplos que peguei na net que usam injeção de contexto de persistência pelo container.
Furada isso também neh? …rs…mesma coisa, fico dependente de WEB.
Premissa verdadeira, conclusão falsa. Sim, EJB’s dependem de um conteiner e praticamente todos os conteineres que suportam EJB’s suportam Servlet’s e JSP’s, mas você pode acessar os EJB’s de fora do conteiner através de um protocolo baseado em RMI (Remote Method Invocation), sem necessidade de alguma camada Web.
Depende. Se o que você entende por “usar a camada Model” é epacotá-la em um .jar e distribuí-la com o desktop ou mobile, realmente, não há sentido algum em usar EJB’s.
Mas veja bem, os EJB’s tem sim seu lugar numa arquitetura em camadas. A idéia é montar uma camada de serviços (servidor) que possa ser acessado por diversos clientes diferentes. Dentro do MVC, essa camada de serviços representa o Model, que contempla entidades e regras de negócio. Assim, fica a cargo de cada cliente implementar o View e o Cotroller.
Você precisa estudar melhor alguns conceitos. Mas está questionando, isso é bom;
A intenção é boa. Mas não considero uma ferramenta essencial. Com injeção de dependências, interceptors e uma boa análise das transações do seus serviços, você resolve boa parte dos problemas que os EJB’s se propõe a resolver. Aliás, boa análise você precisa sempre, com ou sem EJB’s.
[quote]
Outro assunto, tem vários exemplos que peguei na net que usam injeção de contexto de persistência pelo container.
Furada isso também neh? …rs…mesma coisa, fico dependente de WEB.
Aguardo comentários…[/quote]
De maneira alguma. Você pode muito bem usar um conteiner de injeção de dependências como o Guice ou Spring sem um servidor Web. A única diferença é que você tem que iniciar o seu conteiner no método main();
Então, com relação a criar uma camada de serviços com o EJB, achei bem interessando…acessar por RMI e tal.
Mas numa aplicação de pequeno ou médio porte, não vejo muito o porque de usar isso, já que imagino que vá influenciar na performance, certo?
Aí vai de cada caso, cada projeto, correto?
E quanto a questão da injeção do contexto de persistencia pelo container,
deixa eu reformular, a pergunta:
Quando eu disse “Container”, quis dizer “Web Container”.
Nesses casos, tem que criar uma conexão no web container (jboss por exemplo), e acessar pelo JNDI e tal…
Isso que não achei legal fazer, como arquitetura de sistema.
Pelo que estudei até então, acho que a injeção de contexto pelo Spring mais interessante, já que não fico atrelado a Web.
É isso mesmo? Qual sua opinião a respeito?
[quote=bruno_bert]Cara, muito obrigado pelos esclarecimentos.
Então, com relação a criar uma camada de serviços com o EJB, achei bem interessando…acessar por RMI e tal.
Mas numa aplicação de pequeno ou médio porte, não vejo muito o porque de usar isso, já que imagino que vá influenciar na performance, certo?
Aí vai de cada caso, cada projeto, correto?
[/quote]
É bem por aí. De fato os EJBs tem um impacto significativo no desempenho, seja por causa do pooling de instâncias ou por causa de passivation/activation. Mas eu acho que o ponto principal é a complexidade do projeto em si. É complicar o que não precisa ser complicado.
É importante eu ressaltar o seguinte: inversão de controle e injeção de dependências são padrões de projetos, a maneira como eles são implementados é outra história. Você pode até fazer na mão se quiser. A implementação do padrão é outra história. O JEE foi introduzindo injeção de dependências aos poucos, até finalmente definirem uma especificação para isso que é o CDI. O CDI assim como o JPA não depende de um conteiner para ser usado.
Enfim, acho que você tá no caminho. E quer saber do que mais ? Você pode fazer uma ótima aplicação apenas com JDBC (banco dados) e Swing(interface), garanto que o tempo que você vai gastar pra configurar Spring e Hibernate é o mesmo pra fazer pelo menso 1 CRUD com essas tecnologias básicas.