리얼 월드 스터디 회고 - 3

이번 스프린트 주제

• 게시글 단건 조회
• 게시글 여러건 조회 + 페이징

이번 스프린트에서 배운 것

• DTO에 관한 토론
• 변경 여파에 대한 생각 (코드를 변경했을 때, 그 여파가 어디까지 미치는게 옳은가? 최소화하는 방안)
• @PersistenceContext
  • EntityManager 를 빈으로 주입할 때 사용한다.
  • EntityManagerFacotry에서 새로운 EntityManager를 생성하거나 Transaction에 의해 기존에 생성된 EntityManager를 반환함
  • 스프링 빈은 싱글톤 기반이다. → 모든 쓰레드가 공유
    • 하지만, 위 애노테이션으로 EntityManager 를 주입받아도 동시성 문제가 발생하지 않는데, 이유는 다음과 같다.
    • 스프링 컨테이너 초기화 → @PersistenceContext로 주입받은 EntityManager를 Proxy로 감쌈 → EntityManager 호출 시 마다 Proxy를 통해 EntityManager를 생성하여 Thread-Safe를 보장한다.
  출처 : https://batory.tistory.com/497
• 영속성 컨텍스트는 Transaction과 생명주기를 같이한다.
• 트랜잭션이 같으면 같은 영속성 컨텍스트 사용

• 트랜잭션이 다르면 다른 영속성 컨텍스트 사용

출처 : https://ultrakain.gitbooks.io/jpa/content/chapter3/chapter3.2.html

 

 

JpaRepository 의 getReference 메서드는 프록시 객체를 조회한다

• 이는 상속 프록시를 이용한다. (하이버네이트는 CG LIB을 이용해서 이를 구현했다.)
• 프록시는 실제 엔티티의 참조만 보관하고 있다.
• 이는 Lazy 로딩의 근간이 된다.

회고

이번주는 게시글의 단건 조회와 여러건 조회 + 페이징을 구현했다. 구현 자체는 경험했던 내용들이라 쉬웠지만, 여러가지를 신경써가면서 구현 해보고 있는데, 특히 신경쓰는 것들은 아래와 같다.

• 변경에 닫혀있고, 확장에 열려있는가?
  • 아직 확장 까지는 고려할 단계는 아니다. 그래서 변경에 대한 내용들을 위주로 보고있다. 변경에 닫혀있도록 구성하는게 꽤 어려운 것 같다. 특히, 서비스계층과 DTO간의 의존관계를 끊고 싶었으나, update 로직에서는 그걸 끊지 못해 고민중이다. 이 부분은 꾸준히 고민하게 될 것 같다.
• 테스트 코드가 단위 테스트로 작성되었는가?
  • 테스트 코드가 단위 테스트로 작성된 것이 맞는지가 의문이다. 특히, Mockito를 사용할 때는 더더욱 그렇다. Mockito는 내가 행동의 범위를 설정 해주다 보니, 원하는 대로만 테스트가 나오게 되는 것 같아 진정한 테스트가 맞는가.. 라는 고민이 든다. 학습 위주의 프로젝트이기 때문에, 일단은 사용법에 집중하긴 했었으나, 이게 진정 테스트하고자 하는게 맞는가 라는 의문은 앞으로도 해결 해나가야 할 것 같다.

그리고, 스터디원 분들께 정말 많은 것을 배운다. 신경쓰지 못하고 넘어갔던 부분들이나, 신경 써야 하는 부분들을 알게되니 너무 좋다. 특히, 소통이 아주 잘 이뤄진다는게 너무 좋은 것 같다. 이럴 때 일수록, 내가 민폐를 끼치고 있지는 않은지 항상 주의하자.

그리고, 말을 너무 못하는 것 같아서 고민이다😅. 이 부분은 정말 피나는 노력밖에 답이 없는 것 같다. 소프트 스킬도 항상 단련하려는 생각을 하도록 하자. (독성 말투를 주의하자)