Spring @Transactional想必大家都很熟悉，那它是在类上或实现类的方法上和在接口上或接口方法上哪种使用方式是更好的选择呢？

@Transactional介绍

@Transactional 是Spring提供的声明式事务管理，使用起来简单、方便，又能和业务逻辑解耦。

Spring的声明式事务管理在底层是建立在 AOP 的基础之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

Spring的动态代理

Spring AOP是通过动态代理实现的。如果代理对象实现了接口，默认使用JDK的动态代理，反之没有实现接口则使用cglib的动态代理。

言归正传

回到问题上，在正确使用@Transactional注解时，不管@Transactional注解是在类上或实现类的方法上还是在接口上或接口方法上，它的事务功能都是可以实现的，只是选择那种方式更优雅一点而已。

Spring官方文档是这样写的：

Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the @Transactional annotation, as opposed to annotating interfaces. You certainly can place the @Transactional annotation on an interface (or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that Java annotations are not inherited from interfaces means that if you are using class-based proxies ( proxy-target-class=“true”) or the weaving-based aspect ( mode=“aspectj”), then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly bad.

翻译过来大概意思是 Spring官方建议在具体的类或类的方法上使用@Transactional注解，而不是在接口或接口方法上使用。@Transactional也可以在接口上使用，但是这仅限于你使用的是基于接口的动态代理。在java中注解是不会被继承的，如果使用的是基于类的动态代理或者使用aspectj，@Transactional注解的作用就失效了。

总结

Spring 官方建议还是在具体的类上或类的方法上。我本人赞同Spring官方的观点，事务也是一个实现细节，它应该在具体的类上或方法上，到底具体的实现是否是需要事务要看具体的实现细节。

当然，不是说一定要选择将@Transactional使用在具体类或者方法上一定是最好的，如果项目架构更适合用接口的动态代理，将@Transactional注解应用到接口或者接口方法上也是可以的。一定要选择一个最合适自己的，如果没有找到最合适自己的，那就选择一个大多数人都认为好的。

能力一般，水平有限，如有错误，请多指出。如果对你有用点个关注给个赞呗