Tenho que admitir que depois do seu comentario, erickfm8, o meu conceito do Model estava errado. Mas tranquilo, nos frameworks atuais o Model então é abstraído, já que a delegação das actions da View são feitas pelo Controller do Framework, correto?

No caso então, FieroddPJ, vc enchega os EJB's como uma camada de "interfaceamento", ou seja, de comunicação entre objetos ou recursos em locais diferentes. Mas mesmo assim, dependendo da aplicação, pode haver regra de negócio no EJB. Claro que não é nada legal, mas pode ser que seja necessário. Eu sinceramente, e me desculpem e me ajudem se eu estiver falando besteira, gosto bastante do conceito de camadas. Uma camada somente para negócio, uma somente para o Banco (Famoso e Conhecido DAO), etc.

Seria correto então guardar todos os meus EJB's em um pacote e determinar que os mesmos são uma camada apenas de comunicação de objetos em locais diferentes?

Java wrote:
No caso então, FieroddPJ, vc enchega os EJB's como uma camada de "interfaceamento", ou seja, de comunicação entre objetos ou recursos em locais diferentes. Mas mesmo assim, dependendo da aplicação, pode haver regra de negócio no EJB. Claro que não é nada legal, mas pode ser que seja necessário. Eu sinceramente, e me desculpem e me ajudem se eu estiver falando besteira, gosto bastante do conceito de camadas. Uma camada somente para negócio, uma somente para o Banco (Famoso e Conhecido DAO), etc.

Seria correto então guardar todos os meus EJB's em um pacote e determinar que os mesmos são uma camada apenas de comunicação de objetos em locais diferentes?

Ele não diz respeito quanto ao que deve ser utilizado para sua implementação,

Ou vocês vão dizer que uma aplicação .NET não tem MVC ?

erickfm8 wrote:

Ele não diz respeito quanto ao que deve ser utilizado para sua implementação,

DIZ SIM ... POIS FRAMEWORKS COM JSF, e Spring MVC implementa o MVC de acordo com suas "regras"

asaudate wrote: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

asaudate wrote:
MVC é um padrão de projeto arquitetural

asaudate wrote:

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

erickfm8 wrote: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 wrote:

asaudate wrote:
MVC é um padrão de projeto arquitetural

asaudate wrote:

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?

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.

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.

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

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.

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.