-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✏️ [Spring Boot] Kotlin으로 Spring AOP 탈출하기 #13
Comments
재서님 글 잘봤습니다~ lateinit 을 통해서 private fun savePayment(payment: Payment) = Tx.execute {
return paymentRepository.save(payment)
}; 와 같이 코드를 분리가 가능한건 확실히 느꼈는데 AOP 의 관점의 차이일 거 같으나 공통 관심사를 분리하기 위해 매 구현체마다 fun execute() = logging {
this.executeInternal()
} Tx.execute {
return paymentRepository.save(payment)
};
사소한 부분인데 @Test
fun `인가된 사용자는 정상적으로 진행된다`() {
// given
val (user, userPrincipal) = createValidFixture()
// whenb
val result = authorize(MockManager::class, MockManager::execute.name, 1L) {
"some result"
}
// then
assertEquals("some result", result)
} 해당 부분에서 성능적으로도 좋아진 부분은 되게 인상 깊네요. |
일단, kotlin에 매우 익숙치 않은 상태로 억지로 끼워 맞춘 거다 보니, 영양가 있는 답변을 드릴 수 있을 지는 잘 모르겠습니다. ㅋㅋㅋㅋ 1️⃣ 결국은 코드 단에 침범이 되는게 아닌가? 라는 생각은 드네요.이 의견에 저도 동의합니다! 다만, 말씀하신 부분에서 🟡 첫째, 구현부에서 부가적인 관점을 모르게 하는 것은 동일하게 적용할 수 있습니다.
Tx.writeble {} // @Transactional
Tx.readable {} // @Transactional(readOnly=true)
Tx.withSecureDB{} // @Transactional(transactionManager = "SecureDBTransactionManager") 🟡 둘째, 둘 중 우선 순위를 결정한다면, 보다 critical한 이슈를 최소화할 수 있는 방향으로 개선하는 게 더 낫다고 판단했습니다. 여기서 제가 생각한 ciritical한 지점은 runtime 예외 가능성 측면이었습니다. 프로덕트 코드에 무분별한 관심사가 침범하는 것은 지양해야 하는 것이 지당한 판단입니다. 만약, 물론 요건 관점 차이라서, 영수님의 의견도 다양한 관점에서 볼 수 있어서 좋았어요. :) 2️⃣
|
내용 (한줄 요약)
Spring Boot를 너무 사랑한 나머지, Spring Boot를 부정하고자 하는 고군분투. Spring AOP의 좀스런 방식을 탈피하기 위한 내용.
예상 독자
Spring AOP를 탈출하고 싶은 코프링 개발자
블로그 링크
https://jaeseo0519.tistory.com/439
The text was updated successfully, but these errors were encountered: