3
동일한 클래스에있는 메서드간에 메서드 호출을 만들고 트랜잭션에 대한 조언을 적용하는 데 문제가 있습니다.AoP에서 순수 상속 기반 프록시가 올바르지 않은 이유
스프링 프레임 워크. NET 설명서는 구성 및 상속 기반 프록시를 지원하며 스프링이 상속 기반 프록시 (대상이없는 프록시)를 인스턴스화하도록 만들 수 있음을 명시합니다.
그러나 '상속 기반 프록시'조차도 주장하는 바가 아닙니다. 그것들은 인터페이스가 아닌 목표 클래스를 상속 받지만 여전히 대상 객체를 사용합니다. 이것은 같은 클래스의 advice 사이의 call이 적용되지 않는다는 사실로 이어진다.
틀림없이 Spring은 InheritanceBasedAopConfigurer을 사용하여 약간의 노력으로이를 수행 할 수 있지만 여전히 적용 할 개체와 적용 할 조언을 나열해야합니다.
왜 실제 상속 기반 프록시를 피하기 위해 스프링이 농구를 뛰어 넘고 있습니까? 어떤 반 패턴이 빠졌습니까?
1)과 2)에 관해서 : spring.net 팀은 .net에 사용할 수있는 AspectJ와 유사한 라이브러리가 있었으면 다른 선택을했을까요? 또는 Java (기본적으로 "가상")와 .net (기본 가상이 아님) 간의 근본적인 차이점은 무엇입니까? – Marijn
근본적인 차이점은 정적 위버 인 AspectJ입니다. .NET 용 스프링에는 역동적 인 위버 만 있습니다. InheritanceBasedAopConfigurer에는 Java에서 이에 상응하는 것이 없으며 Windows Forms와 같은 일부 특수한 경우에는 AOP를 적용하기 위해 추가되었습니다. – bbaia
통찰력을 가져 주셔서 감사합니다. 구현이 더 복잡 할 수도 있지만 이미 구현되어 있으므로 상속 프록시가 실제로 적용되지 않는 이유를 궁금해 할 것입니다. 인터페이스 디자인과 클래스 디자인은 상속과 컴포지션 기반의 프록 싱에 아무런 차이가 없으며, 어떤 클래스에 접근하더라도 여전히 같은 클래스 내의 메소드 호출에는 적용되지 않을 것입니다. 내 관점에서 볼 때 이것은 수치 스럽다.하지만 나는 그것이 왜 그렇게 행동해야하는지 반성을 듣고 기꺼이 듣겠지만. –