[21기_김준형] spring tutorial 미션 제출합니다. #7
Conversation
- lombok, h2, starter test 의존성
- 가짜 TransactionManager - PlatformTransactionManager 인터페이스에 의존하는 service
There was a problem hiding this comment.
오! 로그 처리를 해 놓으셨네요! 사실 제가 로그를 잘 안 작성하는 버릇이 있어서... 이 코드를 보니까 controller 마다 요청 응답에 따른 자동 로깅이 이런 식으로 진행 될 수 있구나를 잘 볼 수 있는 것 같습니다! 이거는 제가 나중에 잘 써 먹겠습니다 XD 감사합니다
|
|
||
| **생성자 주입시 왜 private final?** | ||
| - final 키워드는 생성시 불변, 선언시 초기화를 시켜주는 것을 강제합니다.<br> | ||
| 선언시 초기화 시켜주는 것을 강제해서 스프링이 컨테이너에 있는 bean을 주입해 줄 수 있습니다. |
There was a problem hiding this comment.
정말 꼼꼼히 정리해 주셨네요! 생성자 주입까지 정리를 안 했는데 이것만 읽어도 많은 정보가 있는 것 같아요!
|
|
||
| **해결은?** | ||
| - fetch join으로 해결할 수 있습니다.<br> | ||
| 하지만 페이징시, to many 관계에서 문제가 발생할 수 있습니다. |
There was a problem hiding this comment.
N+1 문제도 정리 해 주셨네요! 추가로 Fetch join 외에 EntityGraph도 있더라고요! @entitygraph(value = . . .) 라는 식으로 사용되기도 한다네요! (아마 거의 사용하지 않을 것 같아요.) 재사용성이 높지만, 성능이 fetch join과 거의 동일하기에 더 쉬운 방식이나 익숙한 방식으로 사용하는 게 좋을 것 같아요!
There was a problem hiding this comment.
오!! @entitygraph는 몰랐습니다 한번 찾아 봐야겠네요
좋은 정보 감사합니다
| .andExpect(content().string("Greetings from Spring Boot!")); | ||
|
|
||
| } | ||
|
|
There was a problem hiding this comment.
테스트 코드 짜실 때 저랑 비슷한 방향으로 짜는 것 같아요! 참고로 저는 given, when, then 형식에 맞춰서 작성했어요!
|
|
||
| **JPA란?** | ||
| - JPA는 Java Persistence API의 약자로 자바 ORM 기술 표준입니다.<br> | ||
| ORM이란 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 기술입니다. |
There was a problem hiding this comment.
이게 JPA군요... 다음 시간(?)에 배우는 거 같던데 여기서 한 번 보고 갑니다...
|
|
||
|
|
||
| **생성자 주입시 왜 private final?** | ||
| - final 키워드는 생성시 불변, 선언시 초기화를 시켜주는 것을 강제합니다.<br> |
|
|
||
| 좋았던 글<br> | ||
| <https://sabarada.tistory.com/127> | ||
|
|
There was a problem hiding this comment.
PSA 진짜 이해가 안되었는데 이렇게 예제 코드까지.... 존경스럽습니다..
There was a problem hiding this comment.
도움이 되었다면 다행입니다!!
제가 그정도는 아니지만..
칭찬 해주시니 기분이 좋네요ㅎㅎㅎ 감사합니다
| 싱글톤이 뭐가 좋은데? | ||
| - DI를 사용하며 주입받은 객체를 계속해서 생성한다면 많은 메모리를 차지할 것입니다<br> | ||
| 하지만 싱글톤은 객체를 한번만 생성하고 계속해서 사용하기 때문에 메모리를 효율적으로 사용할 수 있습니다 | ||
|
|
There was a problem hiding this comment.
이때까지 메모리를 고려하여 작업한 적이 없는데, 싱글톤이라는 방법으로 메모리 측면에서 이득을 보는 방법이 있네용...
|
|
||
| **해결은?** | ||
| - fetch join으로 해결할 수 있습니다.<br> | ||
| 하지만 페이징시, to many 관계에서 문제가 발생할 수 있습니다. |
| System.out.println("== JDBC Transaction Manager Test 종료 =="); | ||
| } | ||
| ``` | ||
| 실행결과 |
| } | ||
| ``` | ||
|
|
||
| 재시도 로직을 만들어서 성공<br> |
| @Aspect | ||
| public class RetryAspect { | ||
|
|
||
| @Around("@annotation(retry)") |
There was a problem hiding this comment.
오 아래에 requestLogging에 대해서는 포인트컷 시그니처를 만들어서 사용하셨군요!! 서로 다른 방식을 사용하신 이유가 있나요?!
There was a problem hiding this comment.
너무 좋은 리뷰네요..!
포인트컷 시그니처를 사용한 부분은 모든 Controller의 request와 response를 전역적으로 로깅하기 위해,
커스텀 어노테이션을 만들어 포인트컷으로 지정한 부분은 재시도 로직이 필요한 부분에만 명시적으로 적용하기 위해
각각 다른 방식을 사용했습니다.
복잡한 경우를 다루어 보지 않아서
재사용 측면을 생각하지 못했는데,
로그, 트랜잭션, 매개변수 추적 등등의 관심사는 비슷한 부분에서 발생할테니
포인트컷 시그니처를 만드는게 더더욱 중요할 것 같다는 생각이 들었습니다.
구체적으로 찾아보니 이런 재사용 예시가 있더군요..
@Pointcut("execution(* hello.aop.order..*(..))")
public void allOrder(){}
@Pointcut("execution(* *..*Service.*(..))")
public void allService(){}
@Pointcut("allOrder() && allService()")
public void orderAndService(){}
// 여긴 어드바이스
@Around("hello.aop.order.aop.Pointcuts.orderAndService()")덕분에 많이 알아갑니다!ㅎㅎ
+ 혹시 김영한님의 강의를 들으셨나요??
전 넘기면서 들어서 이 부분을 놓친 것 같습니다
No description provided.