Bom, digamos que eu tenha uma aplicação WEB. Como qualquer uma, utilizaremos o MVC.
No Model, eu vou ter a regra de negócio. Na View, todos os elementos de integração. E no Controller, um Framework controlando as requisições.
Mas digamos que eu queira colocar EJB no meu projeto, para integrar a minha aplicação com outro servidor. A questão é: em que camada vai o EJB?
No Model, eu só irei possui as regras de negócio, e EJB não é usado para regra de negócio, então não pode entrar nessa camada. Na camada de View e Controller, nem sonhando.
Então, fica a duvida? Quando usamos EJB em um projeto, estamos abrindo mais uma camada somente para fazer a integração?
Bom, digamos que eu tenha uma aplicação WEB. Como qualquer uma, utilizaremos o MVC.
No Model, eu vou ter a regra de negócio. Na View, todos os elementos de integração. E no Controller, um Framework controlando as requisições.
Mas digamos que eu queira colocar EJB no meu projeto, para integrar a minha aplicação com outro servidor. A questão é: em que camada vai o EJB?
No Model, eu só irei possui as regras de negócio, e EJB não é usado para regra de negócio, então não pode entrar nessa camada. Na camada de View e Controller, nem sonhando.
Então, fica a duvida? Quando usamos EJB em um projeto, estamos abrindo mais uma camada somente para fazer a integração?[/quote]
EJB é uma solução procurando desesperadamente por um problema,então não use,opte por um ‘lightweight container’ como o Spring.
EJB não adiciona mais uma camada na aplicação.
Na verdade EJB ajuda na modularização dos requisitos não funcionais da aplicação, melhorando a organização do código.
EJB entraria um pouco no Controller(parte de segurança) e também na parte de Modelo, por estender e também
adicionar regras que podem ser gerenciadas pelo Container EJB.
Curioso, cada vez mais começo a pensar da mesma forma que vc!
Respondendo a pergunta, eu vejo o EJB, como um componente localizável dentro do servidor que possui uma determinada função, pra mim o EJB é usado como uma segunda camada de controller, ele adiciona a um objeto de negocio todas as suas características, por exemplo, vc tem um componente de negocio responsável pelas informações dos clientes e precisa que esse componente fique disponível via jndi, utilize os recursos de segurança do servidor e etc. Ai vc cria um EJB que disponibilize esse componente de negócio.
Achei o tópico interessante, pois cada vez mais tenho dúvidas sobre a real utilidade dos EJBs.
[quote=raf4ever]
EJB é uma solução procurando desesperadamente por um problema,então não use,opte por um ‘lightweight container’ como o Spring.[/quote]
Na última empresa que trabalhei existiam aplicações que usavam EJB com Glassfish, e os clientes sofriam com isso por causa do consumo exagerado de memória. Como nunca mexi com EJB não sei ao certo o motivo, mas quando excluiram o EJB das aplicações as coisas melhoram.
EJB e MVC não são diretamente relacionados, mas é perfeitamente possível uma aplicação estruturada no padrão MVC utilizar EJB, que oq eu mais vi até hoje, a dúvida original era aonde o EJB entraria nesse caso.
O MVC não é utilizado somente na camada de apresentação, ele geralmente é usado pra organizar a aplicação como um todo, e a maioria dos frameworks web se propõem a realizar a função de controller, intermediando os requests da tela (view) e as respostas de negócio (model).
[quote=erickfm8]cara EJB E MVC NAO TEM NADA HAVER
EJB 3 é excelente a ser usado para sistemas de médio a grande porte (tambem está na especificação Java) eu particularmente prefiro ele do que Spring
[/quote]
O design pattern Model-View-Controler , mais conhecido como MVC trata de uma solução para design de componentes que atuam dentro de uma mesma camada , normalmente na de Cliente e/ou na de Apresentação. As outras camadas usam outros padrões. A de domínio utiliza ~principalmente os padrões Entity e Service e o de integração os padrões Mediator e Bridge.
O MVC trata da separação de responsabilidade entre as classes da camada e não da separação da responsabilidade entre camadas.
"
pessoal leiam o artigo
EJB contem as regras de negócio mais o model é a parte que comunica com essas regras(parte da aplicação). Esse ?resto da aplicação? é genéricamente chamado de ?regras de negocio? por vários autores. Entenda que isto não significa que o model TEM as regras
Concordo com o autor do artigo ao mencionar o MVC com o design de componentes e citando o exemplo do swing, neste contexto aplicando o MVC em um componente faz todo o sentido que o model se comunique com as regras e não as tenha, afinal um botão do swing não teria como saber oq ele teria que fazer até eu codificar.
Agora o artigo reforça ainda mais que os EJBs não estão diretamente relacionados ao MVC e não diz que os EJBs não tem lugar no MVC e eu não entendi como ele ajuda a responder a questão inicial que era “EJB tem Lugar no MVC?”
Pensando dessa forma um EJB (Session ou MDB) corrersponderia a view/controller também pois seriam esses objetos com os quais vc lidaria e eles encapsulariam o model.
O artigo explica o que é MVC , deixei bem claro que o artigo é sobre este, mesmo assim não deixa de ajudar no assunto do forum…
'
“Pensando dessa forma um EJB (Session ou MDB) corrersponderia a view/controller também pois seriam esses objetos com os quais vc lidaria e eles encapsulariam o model.”
isto de maneira alguma, MVC é so na camada de apresentação , EJB fica na camada de negocio
no caso do JSF
a view ser as pagina .xhtml
e o controle seria o FacesContext
Eu posso usar um design pattern em qualquer situação que seja pertinente usá-lo, acho que fui bastante infeliz no meu exemplo … mas não acho que possa dizer que eu uso um pattern sempre pra esse caso e outro sempre para aquele caso.
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?
[quote=Java]
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?[/quote]
Eu sugiro colocar seus EJBs em um pacote especifico, mas por organização não por causa de alguma regra ou padrão.
Sim eu vejo os EJB como forma de tornar meus objetos localizáveis e adicionar a eles todos os recursos que a tecnologia EJB oferece, mas isso não quer dizer que eu sempre crio objetos especificos para serem EJBs, muitas vezes o que eu preciso é apenas disponibilizar objetos já existentes, neste caso eu transformo esses objetos em EJBs o que faz que meu EJB tenha regras de negócio, não vejo problema nisso.
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=erickfm8][quote]
Ele não diz respeito quanto ao que deve ser utilizado para sua implementação,
[/quote]
DIZ SIM … POIS FRAMEWORKS COM JSF, e Spring MVC implementa o MVC de acordo com suas “regras”
[/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.