[quote=legionarioba]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…[/quote]
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?
[quote=Alessandro Lazarotti][quote=legionarioba]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…[/quote]
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?[/quote]
Usar microcontainer é melhor usar um Pattern Adapter usando Ruby, o spring é uma filosofia muito mais dinamica, dividir para conquistar trabalhando com o aspecto de DAO.
Seu dominio é um DAO que se projeta desenhado um pedaços de classes que são refletidas para objetos que persistem dinamicamente na sua camada de dados, via JPA, Hibernate, ou qualquer outro framework que atue nesse paradigma.
[/quote]
Nao entendi o que você disse, tem como explicar melhor?
Seu dominio é um DAO que se projeta desenhado um pedaços de classes que são refletidas para objetos que persistem dinamicamente na sua camada de dados, via JPA, Hibernate, ou qualquer outro framework que atue nesse paradigma.
[/quote]
Nao entendi o que você disse, tem como explicar melhor?[/quote]
DAO é um abstração, que por reflection você persiste dados, você usa determinado patterns(seja Façade, Adapter etc…) para seu domain logic a ser projetado, de forma direta ao controle para camada de dados entre outras que visam comportamento,por frameworks para encapsular essas classe, à contexto de soluções como JPA, HIBERNATE.
[quote=JavaLivros]
Usar microcontainer é melhor usar um Pattern Adapter usando Ruby, o spring é uma filosofia muito mais dinamica, dividir para conquistar trabalhando com o aspecto de DAO.[/quote]
Fórum não é lugar para codificar, Duran. Escreva em português entendível, por favor.
[quote=Alessandro Lazarotti]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?[/quote]
Alessandro ,
O que é caro para um microcontainer como o Spring ?
[quote=Alessandro Lazarotti][quote=legionarioba]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…[/quote]
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?[/quote]
Não é questão de usar EJB com Dao…Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural…a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB…O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo… Este é o equívoco…
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)…
Bom, o java 1.4 foi abandonado ha anos e ainda é usado por ai. O java 5 irá perder suporte (será descontinuado) a partir de 29 de outubro deste ano (sim, no final do mês) Portanto subir para 1.5 é meio atrasado. Deveria ter subido direto para 1.6 que ainda vai durar mais 2 anos por ai. Afinal sintáticamente não ha grande diferença mudar de 1.4 para 1.5 ou para 1.6 e os recursos do 1.6 são bem melhores (porque a API é maior).
Sim é. Pela simples razão que todos os EJB são trasnaction aware e context awere. Em Spring eles não são nenhum dos dois. Vc precisa configurar que quiser funcionalidades equivalentes. Um pojo no spring é mais leve.
[quote=legionarioba][quote=Alessandro Lazarotti][quote=legionarioba]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…[/quote]
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?[/quote]
Não é questão de usar EJB com Dao…Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural…a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB…O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo… Este é o equívoco…
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)…[/quote]
Mas legionarioba], não é pq é EJB que precisa ser “remote”, ele pode ser “local”. Tbm não é pq vc usa EJB que você não pode utilizar qualquer framework de DI para injeção de classes utilitárias.
Sim é. Pela simples razão que todos os EJB são trasnaction aware e context awere. Em Spring eles não são nenhum dos dois. Vc precisa configurar que quiser funcionalidades equivalentes. Um pojo no spring é mais leve.[/quote]
Você pode desarmar os dois lados Sergio. Um EJB só vai ter conhecimento transacional se for CMT, assim como um Spring Bean só vai ser transacional se assim declarado como tal.
Outro ponto é que os serviços relacionados a seus estados ou gerencia de contextos não o tornam mais pesados, muito pelo contrário. Um pool de 10 Stateless gerenciados pode atender mais clientes em solicitações concorrentes do que um bean singleton do Spring, justamente pq é um pool gerenciado. Neste caso um bean, inchado, pode ser mais pesado para responder aos processamentos do que um pool.
[quote=chun]Olha…
nego fala mal do EJB… que é complicado , que é amarrado…
Quero que essa mesma pessoa utilize o Spring-WS uma vez na vida…
Ai sim ela vai descobrir o que é complicar o incomplicavel ![/quote]
chun, só uma pergunta, tu sabes a diferença entre contract-first e contract-last web-services?
JAX-WS e Spring Web-services, apesar de ambos trabalharem com web-services (duh!) o objetivo final é totalmente diferente. Eu mesmo já usei ambos e, cada um é feito para uma situação diferente, não existe melhor ou pior.
Esses teus chiliques quando vê a palavra Spring e a palavra JBoss aqui no GUJ enchem o saco, de boa cara. Nada contra você, mas é que TODO, mas TODO tópico que falam algo que possa “abalar” o EJB e o Glassfish tu já chega na voadora, trollando geral.
[quote=Leozin][quote=chun]Olha…
nego fala mal do EJB… que é complicado , que é amarrado…
Quero que essa mesma pessoa utilize o Spring-WS uma vez na vida…
Ai sim ela vai descobrir o que é complicar o incomplicavel ![/quote]
chun, só uma pergunta, tu sabes a diferença entre contract-first e contract-last web-services?
[/quote]
Sim , porem acho uma abordagem dispensavel em 90% dos casos , e outros 10% é a melhor abordagem… o Srping-WS para variar acha o contrario…
Descordo , MESMO sendo um webservice contract-first , poderia-se ter feito algo bem mais intuitivo e produtivo.
Chiliques ? Isto tem um nome , se chama OPINIAO… agora se vc expressa sua opiniao com CHILIQUES , ai eh uma decisao sua Leia o rodape do minha mensagem
Quanto a voadoras , não sao voadoras… se chama ARGUMENTOS , se voce expressa seus argumentos dando VOADORAS nos outros , ai eh OUTRO problema seu Leia o rodape da minha mensagem
[quote=Leozin]
Eu só vejo você nesse tipo de tópico, só.[/quote]
Que bom assim vc tem o que falar nos topicos
É que o cara usou o maravilhoso ultra-power mega glassfish plus. Se tivesse usado JBoss teria sido bem mais lento.*
*Sarcasmo.[/quote]
Na realidade ele poderia ter utilizado qualquer container , mas neste caso foi o GlassFish…
Mas se voce realmente testou no JBoss e ficou mais lento , reporte aqui :lol:
Agora , se voce nao testou em nenhum deles e apenas fez esse comentario para parecer o “ENGRAÇADÃO DA ESTRELA®” então essa vai para voce fiar feliz hoje:
Leia o rodape do minha mensagem