Почему чистые прокси на основе наследования плохи в AoP

Question

У меня проблема с вызовами методов между методами в одном классе и применением рекомендаций по транзакциям.

В документации Spring Framework .NET говорится, что она поддерживает составные прокси-серверы и прокси-серверы на основе наследования и что вы можете заставить Spring создавать прокси-серверы на основе наследования (прокси-серверы без цели).

Однако оказывается, что даже «прокси на основе наследования» - это не то, на что они претендуют. Они наследуют целевой класс, а не его интерфейс (ы), но они все еще используют целевой объект. Это приводит к тому, что при вызовах между методами в одном классе советы не применяются.

По общему признанию, Spring делает это доступным для некоторых усилий, используя InheritanceBasedAopConfigurer, но вам все еще нужно перечислить объекты, к которым вы хотите применить это, и совет, который вы хотите применить к ним.

Почему Spring прыгает через обручи, чтобы избежать реальных прокси на основе наследования? Какой антипаттерн мне не хватает?

Answer 1

Я вижу несколько причин:

1) Реализация сложнее. Контейнер IoC управляет экземпляром, и для применения чистых прокси на основе наследования вам необходимо работать с этим типом. Вот что делает InheritanceBasedAopConfigurer: он меняет тип перед инициализацией контейнера.

2) Вам нужно пометить ваш метод как виртуальный, если вы хотите, чтобы AOP работал. Это не интуитивно понятно.

3) Прокси-компоненты, основанные на композиции, вынуждают проектировать интерфейс, что является хорошей практикой.