为什么基于纯继承的代理在 AoP 中不好
我在同一类中的方法之间进行方法调用并应用事务建议时遇到问题。
Spring Framework .NET 文档指出它支持基于组合和继承的代理，并且您可以强制 Spring 创建要实例化的基于继承的代理（没有目标的代理）。
然而，事实证明，即使是“基于继承的代理”也不是他们所声称的那样。他们确实继承了目标类而不是它的接口，但他们仍然使用目标对象。这导致在同一类中的方法之间调用时不应用建议。
诚然，Spring 可以使用 InheritanceBasedAopConfigurer 来完成此任务，但您仍然必须列出要应用此功能的对象以及要应用到它们的建议。
为什么 Spring 要竭尽全力避免真正基于继承的代理？我缺少什么反模式？
I have a problem making method calls between methods in same class and having transaction advice apply.
Spring Framework .NET documentation states that it supports compositional and inheritance based proxies and that you can force spring to create inheritance based proxies (proxies without target) to be instantiated.
However, it turns out that even 'inheritance based proxies' are not what they claim. They do inherit target class rather than it's interface(s), but they still use target object. This leads to the fact that on calls between methods in same class advices are not applied.
Admittedly, Spring makes it available to do this with some effort using InheritanceBasedAopConfigurer but you still have to list objects you want to apply this to and advice you want to apply to them.
Why is Spring jumping through hoops to avoid real inheritance based proxies? What anti-pattern am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以看到多个原因：
1）实现更加复杂。 IoC 容器管理实例，并且要应用基于纯继承的代理，您需要处理类型。这就是“InheritanceBasedAopConfigurer”的作用：它在容器初始化之前更改类型。
2）如果你想让AOP工作，你需要将你的方法标记为虚拟方法。这不直观。
3）基于组合的代理强制通过接口进行设计，这是一个很好的实践。
I can see multiple reasons:
1) Implementation more complicated. IoC container manages instance, and to apply pure inheritance based proxies, you need to work on the type. That's what 'InheritanceBasedAopConfigurer' does: it changes the type before container initialization.
2) You need to mark your method as virtual if you want AOP to work. It's not intuitive.
3) Composition based proxies forces design by interface which is a good practice.