인프런 커뮤니티 질문&답변

변경하는 코드는 다음과 같이 구성이 될 예정입니다.

interface Runner {
    fun <T> run(function : () -> T?) : T?
    fun <T> readOnly(function : () -> T?) : T?
}

@Component
class TransactionalAdvice : Runner {
    @Transactional
    override fun <T> run(function : () -> T?) : T? = function()

    @Transactional(readOnly = true)
    override fun <T> readOnly(function : () -> T?) : T? = function()
}

@Component
class Transactional(
    private val advice: Runner
) {
    fun <T> run(function : () -> T?) : T?  = advice.run(function)

    fun <T> readOnly(function : () -> T?) : T? = advice.readOnly(function)
}

TransactionAdvice를 따로 둔 이유는 내부적으로 무언가 후속 조치를 할 수 있게 랩핑하여 확장성을 일부 보장 할 수 있게 하면 좋을듯하여 이렇게 변경하였습니다. 감사합니다!!!!

주말인데도 빠른 답변해주셔서 감사합니다.

private val advice : Runner = Advice()

기존 코드에서 기본 생성자로 값을 넣어주셨는데,

(변경된 코드 기준으로 질문드리자면)

private val advice : Runner = TransactionalAdvice()

이렇게 되어 있던 코드를

private val advice : Runner

이렇게 변경하신 이유는 일반 생성자로 생성 시 프록시가 등록되지 않아서가 맞을까요?

즉, 만약 Runner 인터페이스가 빈에 등록되어 있지 않으면 기본 생성자를 사용해 생성하면 프록시가 동작하지 않으니 만약 없으면 에러 발생하게 처리

이렇게 이해했는데 맞는지 궁금합니다.

좋은 강의 제공해주셔서 감사합니다 😄

넵 이해하신 부분이 맞습니다. 정확히 이해하신거 같아요.

기존 코드로 생성을 하면 프록시가 적용이 되지 않을겁니다. @Transaction 어노테이션이 AOP 프록시를 통해 동작하다 보니 직접 생성자를 통해서 만들어주게 된다면 , Spring이 관리를 하지 않게 되는 문제가 있었죠

말씀하신것처럼 당연하게 에러가 발생을 하게 구성하였습니다.

이렇게 구성한 이유는 AOP의 가장 큰 단점중에 하나가 컴파일 환경에서는 탐지가 안된다는 부분이고, 이 부분을 인터페이스 구현체를 통한다며, Spring 애플리케이션이 Scan하는 과정에서 확인을 해줄 수 있다고 생각을 하였기떄문에 이런 부분을 고려하여 다음과 같이 수정한겁니다!

추가적인 질문이 있다면 편하게 남겨주세요!!