Uma interface Transaction que abstrai a implementação de qualquer api de transação (HibernateTransaction, JDBCTransaction, JTATransaction, etc) não resolve o problema aqui ? Qual a situação onde algo mais complexo se fará necessário ? Essa situação não seria exceção ?
Quanto a AOP, vc usa alguma coisa de AOP no dia a dia ? Qual é a grande sacada de AOP que todos nós devemos usar diariamente em nossos projetos web ? AOP não seria um outro paradigma de programação, que alguns gostam e outros não, preferindo ficar com o bom e velho OO ?
Quanto a Remoting, que parece ser objetos remotos (RMI, RPC, WebServices, etc e tal) isso não anda bem fora de moda? Quem ainda fala com empolgação de webservices hoje em dia ?
Desculpa a pentelhação, Phillip. Sou ignorante desses assuntos e estou fazendo perguntas como um cétido que não consegue ver as vantagens de tudo isso… (Pode me ignorar se tiver sem paciência para me explicar essas coisas complicadas…)
Antes de mais nada eu teria que criar esta tal interface. Se a cada projeto eu tiver que criar a interface é sinal que estou tendo nenhum reuso.
Mesmo assim esse não é o mais importante. COm Spring (e ele usa AOP apra isso, por acaso) eu posso falar na configuração (por isso é declarativo): o método adicionarUsuario é transacional, nível de isolamento X. Isso é parecido com EJBs exceto por funcionar com qualquer POJO.
AOP complementa OO, não substitui. Realmente AOP é mais útil para a construção de frameworks mas uma aplicação grande geralmente implica na criaçãod e um framework interno à esta.
Já precisei do caso clássico de logging mais de uma vez, enviar e-maisl ou mensagens após a conclusão de um método, tornar um método síncrono assíncrono de forma transparente ao cliente, controlar quanto tempo um método demora e abortar em timeout… fora casos simples relacionados ao negócio.
Uma analogia de um AOP simples como do Spring é pensar como filtros HTTP aplicáveis a qualquer POJO gerenciado. Certamente você usa filtros para mais que ‘coisas de framework’ e o fato de trabalhar numa API que não te ofereça filtros iria ser pertubador.
Agora que as pessoas estão entendendo o que dá pra fazer com WebServices você acha que eles estão fora de moda? Google: SOA WebServices
No caso dos outros protocolos, geralmente eles são necessários nos meus projetos recentes e ter um bom nível de abstração/integração é fundamental.
Ah, esqueci de citar também o Acegi para segurança.
Também tem a integração com WebWork, Velocity, FreeMarker, AspectJ, Struts (Argh!), Quartz e mais uma dúzia de coisas
O Spring não é só um “framework” mas é também um conjunto de ferramentas e utilitários pra facilitar a vida do programador, e as coisas realmente ficam bem “coladas” lá dentro
Pra quem tiver com coragem, os dois primeiros livros do Rod Johnson sobre o Spring são ótimos (o primeiro que ele discute o desenvolvimento J2EE e o outro que ele já discute o Spring e outros frameworks "leves).
E pra começar a brincar com o Spring, tem esse livrão aqui:
[quote=Maurício Linhares]os dois primeiros livros do Rod Johnson sobre o Spring são ótimos (o primeiro que ele discute o desenvolvimento J2EE e o outro que ele já discute o Spring e outros frameworks "leves).[/quote]puts, esse primeiro eu tenho!!! nunca lí ok? baixei o pdf mas ainda não consegui tempo pra ler.
bom saber, valeu mesmo pela dica.
com certeza vou precisar ler, vcs estão falando tão bem do spring que eu ainda não consegui formar opinião sobre os contras.
(Pode me ignorar se tiver sem paciência para me explicar essas coisas complicadas…)
