[转载] Rod Johnson关于AOP Transaction的一段文字

[原作者] Rod Johnson
[链接]     http://www.theserverside.com/news/thread.tss?thread_id=27208#129224
[点评]    SpringFramework的奠基者、领导者和主要开发者之一的Rod Johnson，说出来的话自然有些分量，虽然这段话只是在回答别人问题的时候说的，但其中包含了很多信息，如下：

•  Spring的AOP对于Transaction managment来说，由于目前所见到的AspectJ的Transaction实现；
•  Spring 1.1中将整合对AspectJ的支持，非常棒！
  
•  Spring 1.1 RC1将很快发布，很有可能在下周的周末，值得期待。

[原文]

Jacob

I recently read AspectJ in Action from Manning Press. It discusses transactions too, but through AspectJ and the resulting efforts are not container dependent. I think that Spring as an IoC container is great, but if people want Aspect Oriented features, just do yourself a favor and learn AspectJ in Eclipse with the AJDT plugin. None of this runtime Proxy of Proxy of InvocationHandler stuff to slow down your application.

Rod 的回答：
AspectJ is a great language: no argument there. I also like Laddad's book. But AspectJ is not the perfect solution to all AOP problems, and often simpler, lower-tech, solutions are compelling.

Transaction management is a case in point. For a lot of middleware aspects, which typically require only method interception, AspectJ's full power doesn't come into play, and it has no great advantage over Spring AOP, DynAOP or another proxy based framework. For example, Laddad's book is excellent, but the transaction examples are just that--examples of how you might start work on transaction management in AspectJ. Spring's transaction interception is way more powerful than anything I've seen implemented using AspectJ. Of course you can implement whatever sophisticated of transaction interception you like with AspectJ--it's just that what really matters is how you abstract the underlying transaction infrastructure, not what AOP framework you use. The performance overhead of a proxy-based approach is insigificant in such cases.

So there is a valid case for the subset of AOP that proxy-based solutions provide. (Also they can do one or two things that are hard to do with "full-blown AOP," such as maintain different advice for different objects of the same class.)

Having said that, I believe that AspectJ is going to become increasingly important as we come to understand the full implications of AOP. So one of the major features in Spring 1.1 is AspectJ integration. This will allow AspectJ aspects to be configured by the Spring IoC container using Dependency Injection, which brings similar benefits to applying DI for classes. Both Adrian Colyer and I are very excited about this, and both Spring and AspectJ teams are working together. Support for the core AspectJ integration is already in Spring CVS and will be released with Spring 1.1 RC1 (probably end of next week). I'm also working on some samples, which will probably be released separately slightly later. The Spring/AspectJ integration opens up some interesting possibilities.

Beyond that, we're looking at using AspectJ pointcuts to target Spring AOP advice. This relies on AspectJ changes--they are going to expose an API for Spring and other tools to use at runtime.

Another interesting area is implementing Spring services as "native" AspectJ aspects. Thus we'll provide a transaction aspect, probably in the Spring 1.2 timeframe, although I might release it with the samples.

Rgds
Rod