EJB tem Lugar no MVC?

[maior_abandonado]

[quote=asaudate]Caros,

MVC é um padrão de projeto arquitetural. Ele não diz respeito quanto ao que deve ser utilizado para sua implementação, apenas dá a idéia do que deve ser feito. Não cabe dizer que EJB tem ou não tem lugar no MVC porque, sendo MVC apenas um modelo abstrato, ele não proíbe ou reforça qualquer tecnologia - aliás, isso é válido inclusive para a linguagem de programação em si. Ou vocês vão dizer que uma aplicação .NET não tem MVC ?

No entanto, é óbvio que - para tudo que envolve TI - deve haver bom senso. Não é uma decisão bem fundamentada querer usar EJB num sistema de padaria (a não ser que seja uma padaria imensa). Assim como não dá pra falar que um revendedor online, tipo um submarino, deve usar somente servlets e jsp (e, se bobear, jdbc pra acessar a base de dados).

Pra finalizar… nem me aventuro a entrar na discussão Spring x EJB. Isso porque cada um tem vantagens e desvantagens - eu quase sempre utilizo EJB. Em alguns casos, utilizo Spring e, em casos mais raros, os dois em conjunto (pois é, eles não são mutuamente excludentes). O que não dá é ser xiita e fechar a cabeça e falar “eu só uso Spring porque EJB é bobo, chato e cabeça de melão”.

[]'s

P.S: Ri muuuito com a frase “EJB é uma solução procurando desesperadamente por um problema”. =D[/quote]

concordo com tudo isso que o asaude falou, apenas complementando, o EJB não está diretamente relacionado ao “conceito de camadas” mesmo, mas ele visa facilitar o ato de evitar alguns problemas ou dificuldades que você pode ter especialmente no modelo, sim. Por exemplo, é nessa camada que você pode ter processamentos mais pesados, para contornar isso você pode ter pools de instâncias dessas regras de negócio pesadas, balanceamento de carga, pode processa isso de forma assíncrona com a regra de negócio em uma fila JMS por exemplo, de forma simplificada. Além disso você pode ter outras facilidades sim como injeção de dependência ou JTA.

Apenas para considerar, o EJB não está diretamente ligado ao conceito de “camadas”, mas honestamente não vejo muita lógica em usa-lo fora do modelo…

[erickfm8]

asaudate , tudo bem?

em um sistema que use EJB e JSF , considerando o MVC

o que vc consideraria como parte de view , controller , model?

eu sei que isso varia, mais o que VC , consideraria?

[el_loko]

MVC é um padrão de projeto arquitetural

Não implementam com suas “regras”, implementam da maneira que eles acham correto. Não faça confusão entre uma implementação de MVC e o padrão em si - seria mais ou menos o mesmo que falar que se você usa injeção de dependências, você usa Spring. Usar um framework que implementa um padrão não quer dizer que você é obrigado a usar o framework para implementar o padrão.

Além disso, não se esqueça de não confundir “MVC” com “camada de apresentação”. Além de tudo, MVC não está restrito à apresentação (como, aliás, o Sergio Taborda deixou implícito no blog dele). Isso quer dizer que você pode usar frameworks baseados em MVC que não sejam voltados à apresentação.

[]'s

Sempre tive uma dúvida quanto ao MVC e a palavra “arquitetura”. Já vi algumas discussões sobre o MVC ser ou não um pattern arquiteturial.
Se o MVC é aplicado em apenas 1 camada, como ele pode ser considerado um padrão arquiteturial?

[Alexandre_Saudate]

[quote=erickfm8]asaudate , tudo bem?

em um sistema que use EJB e JSF , considerando o MVC

o que vc consideraria como parte de view , controller , model?

eu sei que isso varia, mais o que VC , consideraria?[/quote]

Tipicamente, em sistemas usando JSF, fica lógico que as telas são View, Managed Beans são controllers e EJB’s são models. O caso é que isso é transiente, de maneira que essa mesma camada de EJB’s pode, por sua vez, ser repartida de novo, como se fosse um novo MVC. Repare que, dentro de um modelo MVC, a View não está restrita ao que o usuário final vê, mas sim, à maneira como determinada camada se apresenta. Assim, um EJB de fachada pode ser considerado View? Sim, pode! E dentro da camada de modelo, dentro do servidor, eu posso ter MVC de novo, então? Sim, posso.

Ou seja, você não deve se ater ao framework e depois ao padrão, você deve entender o que é o padrão, pra que serve e, então, você vai entender porque um framework (nesse caso, JSF) implementa esse padrão.

[]'s

[Alexandre_Saudate]

[quote=el_loko][quote=asaudate]
MVC é um padrão de projeto arquitetural
[/quote]

Não implementam com suas “regras”, implementam da maneira que eles acham correto. Não faça confusão entre uma implementação de MVC e o padrão em si - seria mais ou menos o mesmo que falar que se você usa injeção de dependências, você usa Spring. Usar um framework que implementa um padrão não quer dizer que você é obrigado a usar o framework para implementar o padrão.

Além disso, não se esqueça de não confundir “MVC” com “camada de apresentação”. Além de tudo, MVC não está restrito à apresentação (como, aliás, o Sergio Taborda deixou implícito no blog dele). Isso quer dizer que você pode usar frameworks baseados em MVC que não sejam voltados à apresentação.

[]'s

Sempre tive uma dúvida quanto ao MVC e a palavra “arquitetura”. Já vi algumas discussões sobre o MVC ser ou não um pattern arquiteturial.
Se o MVC é aplicado em apenas 1 camada, como ele pode ser considerado um padrão arquiteturial?[/quote]

Porque, de uma forma ou de outra, ele rege como uma camada se comporta. Dessa maneira, ele não vai estar no nível de relacionamento de um bean pra outro, mas sim, de vários beans. Além disso, o MVC não se preocupa em resolver um problema específico, mas sim, prevenir problemas de alto encapsulamento, baixa coesão, etc; que são, por sua vez, preocupações de nível arquitetural.

[]'s

[erickfm8]

Tipicamente, em sistemas usando JSF, fica lógico que as telas são View, Managed Beans são controllers e EJB’s são models. O caso é que isso é transiente, de maneira que essa mesma camada de EJB’s pode, por sua vez, ser repartida de novo, como se fosse um novo MVC. Repare que, dentro de um modelo MVC, a View não está restrita ao que o usuário final vê, mas sim, à maneira como determinada camada se apresenta. Assim, um EJB de fachada pode ser considerado View? Sim, pode! E dentro da camada de modelo, dentro do servidor, eu posso ter MVC de novo, então? Sim, posso.

Discordo

.xhtml é a view
FacesContext é o controlador
ManagendBean é/“pode” ser o model

Model-View-Controller (MVC)

The MVC pattern’s purpose is to decouple Model (or data) from the presentation of the data (View). If your application has more than one presentation, you can can replace only the view layer and reuse code for the controller and model. Similarly, if you need to change a model, the view layer remains largely unaffected. Controller handles user actions that might result in changes in the model and updates to the views. When a user requests a JSF page, the request goes to FacesServlet. FacesServlet is the front controller servlet used in JSF. Like many other Web application frameworks, JSF uses the MVC pattern to decouple the view and the model. To handle user requests centrally, the controller servlet makes changes to the model and navigates users to views.

FacesServlet is the controller element in the JSF framework which all user requests go through. FacesServlet examines user requests and calls various actions on the model using managed beans. Backing, or managed, beans are an example of the model. JSF user interface (UI) components represent the view layer. The MVC pattern helps to divide tasks among developers who have different skill sets so tasks can be carried out in parallel; that is, GUI designers can create JSF pages with rich UI components while back-end developers can create managed beans to write business-logic specific code.

referência

Design with the JSF architecture

como vc pode ver no tutorial da IBM…

[raf4ever]

Discordo
.xhtml é a view
FacesContext é o controlador
ManagendBean é/“pode” ser o model

Tbm concordo com a definição do asaudate.
ManagedBean é pra receber dados do .xhtml e invocar o model,então atua como controller.

[erickfm8]

mais temos fontes segura no site da IBM que afirma que o controller nao é o ManagendBean

[erickfm8]

Controller - The controller translates the user’s interactions with the view into actions that the model will perform. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in an enterprise web application, they appear as GET and POST HTTP requests. Depending on the context, a controller may also select a new view – for example, a web page of results – to present back to the user.

referência : http://java.sun.com/blueprints/patterns/MVC-detailed.html

[raf4ever]

Depending on the context, a controller may also select a new view – for example, a web page of results – to present back to the user.

Traduzindo isso em código,seria assim:

public class UmManagedBean{

  public String salvar(){
    salva();
return "salvou";
}
}

Correto? :lol:

[erickfm8]

este ultimo não esta se referindo ao JSF, esta se a Servelt puro.

Mesmo assim no meu ponto de vista ao falar

“they appear as GET and POST HTTP requests”

isto pra mim é feito internamente.

…

Ja no JSF, os metodos salvar,(“aqui por exemplo vc pode verificar se o cliente precisa ter algum requisito para ser salvo”), isto é logica de negócio é o model

[Alexandre_Saudate]

[quote=erickfm8]
este ultimo não esta se referindo ao JSF, esta se a Servelt puro.

Mesmo assim no meu ponto de vista ao falar

“they appear as GET and POST HTTP requests”

isto pra mim é feito internamente.

…

Ja no JSF, os metodos salvar,(“aqui por exemplo vc pode verificar se o cliente precisa ter algum requisito para ser salvo”), isto é logica de negócio é o model[/quote]

Por isso eu digo e repito pra nao esquecer a motivacao do pattern. Uma vez que voce diz q os managed beans sao model, entao vc esta amarrando-os ao JSF. Dessa maneira, vc nao consegue porta-los para outras tecnologias, talvez outras linguagens. Assim, da maneira como voce esta descrevendo, MVC perderia sua motivacao.

[]'s

[erickfm8]

rsrsrs estou falando isso com base nos artigos lidos, passei referência pra vc…

Então vc discorda com o tutorial da IBM

asaudate acho que algum lugar vc mesmo citou que MVC cada framework implementa de uma forma diferente certo?

então é obvio que se vc mudar de JSF para outra framework que implementa MVC de outra maneira, a implementação vai mudar…

[Alexandre_Saudate]

Sim, a implementacao muda, mas o conceito deve permanecer. O struts tem o action controller, o jsf tem tem o facesservlet, o swing tem os listeners… o caso eh q o modelo deve permanecer sempre o mesmo, independente de qual desses eu vou usar. (Alias, no caso do jsf, se os managed beans fossem modelo, seria o modelo mais orientado a string q jah vi =p)

[]'s

[erickfm8]

são analisados nas seções a seguir três destes frameworks: JavaServer
Faces (JSF, 2005), Struts (2005) e Spring MVC, o módulo MVC do framework
Spring (2005) apresentado no capítulo anterior.

O framework usualmente traz o controlador do MVC pronto. Este é
implementado através de um servlet que deve ser configurado ao instanciar o
framework. O controlador mapeia requisições em classes da instância que
realizam o padrão de projeto comando (Command) (Gamma et al., 1995). A visão

referência
http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0410823_06_cap_04.pdf

Você concorda que os controladores desses framework ja vem pronto? no caso do JSF o FacesContext?
Não entendi porque orientado a String, se agente trabalha com objetos dentro dele, isso que vc falou depende do jeito que cada um programa =S…
Tem muita lógica de négocio no MB, e o model contem a lógica de negócio!..

[Alexandre_Saudate]

Eu disse que eh orientado a string porque obriga o MB a retornar uma string, para que ele possa achar a pagina. Note que isso, alias, eh um comportamento tipico de um controlador.

Quanto a referencia que voce postou, eu jah conhecia. O caso eh que o que esses frameworks trazem eh uma casca do controller. O comportamento especifico deve ser definido pelo programador, atraves dos managed beans.

Note que o mvc nao delimita que apenas uma classe deve ser usada como controller (como eu falei ha uns posts atras).

[]'s

P.S: A referencia q voce postou diz “usualmente”, nao diz sempre.

[erickfm8]

"Eu disse que eh orientado a string porque obriga o MB a retornar uma string, para que ele possa achar a pagina. Note que isso, alias, eh um comportamento tipico de um controlador. "

ele reforna uma string para o FacesServlet e o FacesServlet que faz este redirecionamento.

"A referencia q voce postou diz “usualmente”, nao diz sempre. "

sim, por isso que não estou falando de todos os framework até porque não conheço, estou falando e especifico do JSF, que este sim tras o controlador pronto.

View manda um requisição ,FacesServlet (Controlador - internamente passa para o modelo) ,

[Alexandre_Saudate]

Para um framework ser considerado MVC, ele nao pode afetar a maneira como o modelo eh feito. Senao, ele fere o proprio conceito de MVC.

[]'s

[erickfm8]

"Para um framework ser considerado MVC, ele nao pode afetar a maneira como o modelo eh feito. Senao, ele fere o proprio conceito de MVC. "

Concordo ;D

[Poucatrancas]

Então por que o JSF obriga ao programador criar managedbeans especificos que irão retornar strings para controle de navegação ?

Muito esquisito, não me entra na cabeça ManagedBeans como Model, nem faz muito sentido.