EJB tem Lugar no MVC?

Jaba:

E ai Pessoal.

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?

EJB é uma solução procurando desesperadamente por um problema,então não use,opte por um ‘lightweight container’ como o Spring.

EJB é teu model, pois ele cuida da regra de negócio, controle transacional, etc.

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.

raf4ever:

EJB é uma solução procurando desesperadamente por um problema,então não use,opte por um ‘lightweight container’ como o Spring.

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.

Também acho que o Spring é uma ótima solução.

Mas sobre o post, EJB e MVC não tem nada haver.

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

MVC é um DesingPatters usado SOMENTE na CAMANDA de apresentação, no caso de vc usar Framework (JSF entre outros) esse por si ja implementa MVC.

Leia este artigo para entender sobre MVC , foi o melhor artigo que eu li até hoje

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).

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

Sério?Pq?

"

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?

Model ele acessa as regras, ele não TEM as regras de negocio ,

EJB tem regras de negocios

Correto,em casos extremamente especiais o model não esta abstraido,isso depende mtu. mais o pensamento esta certo.

O ejb pode ter regra de negócio sim, sem problemas, mais vc pode usar o padrão FACADE da uma pesquisada…

o correto e vc guardar os objetos em pacotes diferentes sim,

e só para resaltar um coisa, o padrão DAO vc usa, quando utiliza JDBC puro ,quanto vc usa JPA com entidade agente chama de EAO

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?

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.

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

DIZ SIM … POIS FRAMEWORKS COM JSF, e Spring MVC implementa o MVC de acordo com suas “regras”

Tenho quase certeza que ninguem aqui pensa isso ;D

erickfm8:

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”

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

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

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…

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?

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?

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?

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

el_loko:

asaudate:

MVC é um padrão de projeto arquitetural

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?

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

Discordo

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

referência

como vc pode ver no tutorial da IBM…

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

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

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

Traduzindo isso em código,seria assim:

public class UmManagedBean{

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

Correto? :lol:

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

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

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

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…

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

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!..

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.

"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) ,

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

"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

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.

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…

Assino embaixo.

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.

Aguardo comentários…

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.

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…

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();

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?

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?

Valew

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?

É 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.

Cara, valew…bom falar com queme stá mais tempo no ramo…rs

Abraço

Por que as empresas pedem mais EJB que MVC ???

Quais as vantagens de um EJB emcima do MVC ???

Como ficaria a sua regra de negocio , ficaria no EJB ou teria outro Objeto Regra de Negocio, alguem poderia fazer um exemplo ???

Obrigado !