3

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?

Marijn
  • 10,367
  • 5
  • 59
  • 80
Nikola Radosavljević
  • 6,871
  • 32
  • 44

1 Answers1

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.

bbaia
  • 1,193
  • 7
  • 8
  • With regard to 1) and 2): Would the spring.net team have made different choices if there would have been AspectJ-like aop libraries available for .net at the time? Or is the fundamental difference between Java (by default methods are "virtual") and .net (default not virtual) leading here? – Marijn Jan 20 '12 at 10:14
  • 1
    The fundamental difference is AspectJ, a static weaver. Spring for .NET only has a dynamic weaver. InheritanceBasedAopConfigurer have no equivalent in Java, it has been added to apply AOP in some special cases like Windows Forms. – bbaia Jan 20 '12 at 18:05
  • Thanks for your insight, although i cant fully agree. It's possible that implementation is more complicated, but it is already implemented so i wonder why inheritance proxying is not really applied when you say you want it. Interface design vs class design will make no difference to inheritance vs composition based proxying, and whichever approach you take advices still wont be applied to method calls within same class. In my perspective this is a shame, although i'd gladly hear counterargument why it should work as it does. – Nikola Radosavljević Feb 29 '12 at 19:59