为什么纯继承代理在AoP中不好

我在同一类中的方法之间进行方法调用以及应用事务建议时遇到问题

SpringFramework.NET文档声明它支持组合代理和基于继承的代理，您可以强制Spring创建基于继承的代理（没有目标的代理）进行实例化

然而，事实证明，即使是“基于继承的代理”也不是他们所声称的。它们确实继承了目标类而不是它的接口，但它们仍然使用目标对象。这导致了一个事实，即同一类通知中的方法之间的on调用不适用

诚然，Spring通过使用

InheritanceBaseDaopConfiger

做了一些努力就可以做到这一点，但您仍然需要列出您要应用此功能的对象和建议

---

为什么Spring要跳转来避免真正的基于继承的代理？我缺少什么反模式？

我可以看到多个原因：

1） 实现更加复杂。IoC容器管理实例，要应用纯粹基于继承的代理，您需要处理该类型。这就是“InheritanceBaseDaopConfiger”的作用：它在容器初始化之前更改类型

2） 如果希望AOP工作，则需要将方法标记为虚拟方法。这不是直觉

---

3） 基于合成的代理强制按接口设计，这是一种很好的做法。

关于1）和2）：如果当时有类似AspectJ的aop库可用于.net，spring.net团队会做出不同的选择吗？或者说Java（默认方法是“虚拟的”）和.net（默认不是虚拟的）之间的根本区别就在这里？根本区别在于AspectJ，一个静态编织器。Spring for.NET只有一个动态编织器。InheritanceBaseDaopConfiger在Java中没有等价物，它被添加用于在某些特殊情况下（如Windows窗体）应用AOP。感谢您的见解，尽管我不能完全同意。实现可能更复杂，但它已经实现了，所以我想知道，当您说需要继承代理时，为什么没有真正应用它。接口设计与类设计对继承与基于组合的代理没有任何区别，而且无论您建议哪种方法，都不会应用于同一类中的方法调用。在我看来，这是一种耻辱，尽管我很高兴听到有人反驳为什么它应该如此有效。