MAS NÃO CONCORDO COM O AUTOR DO ARTIGO QUE AFIRMA QUE PARA “APLICAÇÕES MAIS ROBUSTAS” É PREFERÍVEL UTLIZAR O SPRING.
O AUTOR AINDA TEVE A PETULÂNCIA DE AFIRMAR QUE O EJB SÓ É RECOMENDÁVEL PARA APLICAÇÕES DESENVOLVIDAS EM UM CENÁRIO “MAIS SIMPLES” !!
EU TRABALHEI COM UMA APLICAÇÃO BASTANTE ROBUSTA E COMPLEXA UTILIZANDO EJB 3 E NÃO TIVE PROBLEMA ALGUM, PELO
CONTRÁRIO O EJB AJUDOU PRA CARAMBA !! É MUITO BOM !!
EU ACHEI O AUTOR MEIO TENDENCIOSO PUXANDO A SARDINHA PRO LADO DO SPRING.
MAS DEVEMOS PERDOA-LO POIS TEM SOMENTE 4 ANOS DE EXPERIÊNCIA COM JAVA !!
[/quote]
Alguma outra pessoa que tenha lido o artigo ou o próprio autor confirmam isso? Que foi falado que ejb é recomendável para cenários mais simples?
O artigo menciona isso apenas na conclusão de Gerenciamento de Transações, e não na conclusão final. Portanto, em nenhum momento o artigo menciona que o EJB 3 deve ser utilizado para cenários mais simples (até porque dizer isso seria uma mentira).
O artigo menciona isso apenas na conclusão de Gerenciamento de Transações, e não na conclusão final. Portanto, em nenhum momento o artigo menciona que o EJB 3 deve ser utilizado para cenários mais simples (até porque dizer isso seria uma mentira).[/quote]
certo!!! Valeu Rafael!! Sabia que tinha algo estranho mesmo, agora tá tudo esclarecido!!
Eu não disse que o Spring não faz transação declarativa entre vários beans, o que eu disse é que fatalmente o desenvolvedor terá que fazer o controle na mão, como eu tive que fazer em mais de uma situação.
Nós estamos falando de EJB 3 e Spring 2.x. Quando voce quiser fazer um comentário como esse, para evitar o ridículo, leia as mensagens postadas anteriormente, assim você se contextualiza.
Quando a gente fala em cenário mais simples, estamos nos referindo diretamente as necessidades de controle transacional e não alegando que EJB não possa ser utilizado em aplicações grandes ou complexas. Quando há a necessidade de configurar o nível de isolamento de uma transação usando a tecnologia EJB, por exemplo, é inevitável fazer tal operação manualmente na conexão. É certo que em várias aplicações isso não vai ser necessário, então ótimo, mas quando for, tal configuração pode depender de cada container ou em codificação. Outro exemplo é envolver objetos de negócios na mesma transação que não sejam EJBs e isso implica em lidar manualmente com a API da JTA. Então, quando você tem esse cenário, usar o mecanismo de controle transacional começa a se tornar complexo.
Se você usa apenas EJBs e suas necessidades são apenas a nível de controle de propagação, então esse é o cenário trivial e usar a tecnologia EJB, especialmente a partir da versão 3, torna tudo menos complicado. E claro, não importa o tamanho da aplicação ou a complexidade do negócio.
Usar vários beans na mesma transação no Spring não implica em implementar na mão o controle transacional. Se isso fosse verdade, de que adiantaria chamar de controle transacional? Também não confunda gerenciamento de transações com a injeção do EntityManager. São duas coisas diferentes. E sim, no Spring há a possibilidade de injetar o EntityManager usando a mesma anotação que se usa em EJB.
A escolha sempre depende de requisitos. Se EJB resolve bem, porque partir para Spring? O contrário também é verdade.
Quando fizemos o artigo, nós sabíamos que o título iria causar essa idéia de comparação ou de definição de qual seria o melhor.
Vou copiar um trecho que escrevi no meu blog:
[quote]A idéia e intuito da criação do artigo não era de definir que X é melhor do que Y, e sim a idéia de compararmos os principais recursos das duas tecnologias (segurança, transações, mensageria, etc) e mostrar para o desenvolvedor que cabe apenas a ele escolher qual tecnologia trará mais benefícios. Isso não faria o menor sentido, até porque já existemdiversascomparaçõesna internet sobre esse assunto e até hoje os caríssimos Rod Johnson e Bill Burke travam uma guerra interminável sobre esse assunto.
[/quote]
Como mencionado acima, a idéia era comparar os principais recursos que as duas tecnologias pregam. É claro que tivemos que expor as nossas opiniões e em cada tópico houveram debates (com códigos e pesquisas) a respeito das duas tecnologias, comparando dificuldades, facilidades, tempo de desenvolvimento, recursos disponíveis para consulta e vários aspectos.
Desta forma, seria uma injustiça dizer no artigo que as duas tecnologias cumprem de forma semelhante todos os recursos abordados. Para isso, o JCP está correndo atrás e já irá trazer diversas melhorias na versão 3.1 do EJB.
AccountingImportResult result = (AccountingImportResult)transactionTemplate.execute(new TransactionCallback(){
public Object doInTransaction(TransactionStatus ts) {
try{
/*chamadas a operações de vários beans com inserts, updates e delete em várias tabelas*/
}catch (Throwable e) {
ts.setRollbackOnly();
//...
}
return null;
}
});
Acredito que o objetivo desse tópico já foi alcançado, que era expor uma crítica ao artigo citado, mas sinto que algumas declarações estão sendo levadas para o lado pessoal e isso nunca é construtivo.
Fica a minha sugestão para que numa próxima edição da Mundo Java não seja cometido os mesmos erros e assim tenhamos uma revista com ainda mais qualidade.
Nota: quando me refiro aos erros, me refiro a forma como o artigo foi redigido totalmente parcial e tendencioso. Isso não é o que se espera de um artigo publicado numa revista com grande circulação como a Mundo Java.
[quote=gilberto.souza]Acredito que o objetivo desse tópico já foi alcançado, que era expor uma crítica ao artigo citado, mas sinto que algumas declarações estão sendo levadas para o lado pessoal e isso nunca é construtivo.
Fica a minha sugestão para que numa próxima edição da Mundo Java não seja cometido os mesmos erros e assim tenhamos uma revista com ainda mais qualidade.
Nota: quando me refiro aos erros, me refiro a forma como o artigo foi redigido totalmente parcial e tendencioso. Isso não é o que se espera de um artigo publicado numa revista com grande circulação como a Mundo Java.
At.
[/quote]
Gilberto,
Acho que você tem razão e agora mais ainda por que o Maurício Linhares não soube nem mesmo o que mais argumentar…, volte sempre ai para ajudar agente a entender melhor essas tecnologias …
[quote=Marcio Duran]
Gilberto,
Acho que você tem razão e agora mais ainda por que o Maurício Linhares não soube nem mesmo o que mais argumentar…, volte sempre ai para ajudar agente a entender melhor essas tecnologias …
Abraçosss[/quote]
Aonde que o Maurício não soube argumentar? Pode me mostar por favor?
Acho que não, pois você não deu respostas contundentes sobre os seus questionamentos que foram respondidos.
Você poderia nos informar quem ou quais são as pessoas deste tópico que estão levando para o lado pessoal? Não vejo ninguém que esteja levando para esse lado.
Como foi dito por alguns usuários neste post, você poderia escrever um artigo para a MundoJava expondo as suas opiniões, é simples.
Ainda estou esperando por motivos concretos a respeito dessa sua opinião.
Cara,
não sei se entendi direito, mas se vc precisa de varias chamadas ao banco dentro de uma transação atomica, vc pode fazer isso de forma muito simples, somente declarando no xml do Spring ou via anotação.
Vc marca um metodo como transacional e a partr disso todas as chamadas fazem parte da transacao. E vc pode usar uma granularidade mais fina ainda se quiser, mas tudo via configuração.
Eu nunca precisar fazer programaticamente.
[quote=Leozin][quote=Marcio Duran]
Gilberto,
Acho que você tem razão e agora mais ainda por que o Maurício Linhares não soube nem mesmo o que mais argumentar…, volte sempre ai para ajudar agente a entender melhor essas tecnologias …
Abraçosss[/quote]
Aonde que o Maurício não soube argumentar? Pode me mostar por favor?[/quote]
Rafael, deixa eu entender a sua sugestão: Você quer que eu escreva um ?artigo? para a Mundo Java (revista focada em tecnologia e metodologias), expondo minha crítica a um dos artigos publicado num revisão anterior? Isso não me parece lógico. Mas caso a revista tenha um espaço para sugestões dos ?leitores? ai sim, isso se torna uma opção válida.
Não queria partir para esse lado, mas dado a qualidade das suas respostas e sua falta de maturidade para receber as críticas me vejo obrigado a perguntar quantos anos de idade você tem, me surpreenderia se você dissesse que tem mais de 13 anos.