#3 JPA 실무 - 요구사항 분석 및 구현

서비스 설계

Controller에서 되도록 Repository에 직접 접근하는 것을 피했는데 실무적인 관점에서는 구현의 편의성을 위해서 허용하는 것도 나쁘지는 않음. 다만 참조 방향만 흐트러지지 않도록!

repository 설계

• jqpl은 table을 대상으로 조회를 수행하는게 아니라 엔티티에 대해서 조회한다고 생각.
• Repository annotation은 SpringApplication 하위에 자동으로 component를 scan(component scan 범위 지정)
• @PersistenceUnit으로 EntityManagerFactory로 지정가능하나 쓸 일이 많이 없음

service 설계와 Transactional

• javax와 spring이 제공하는 annotation 중 spring이 기능이 풍부하기때문에 더 권장
• 되도록이면 repository 조회는 전부 다 transactional을 가지는게 좋음
• readOnly를 적절히 잘 사용하면 최적화 됨. dirty checking 등 그건 찾아봐야 함.
• class scope에 Transactional(readOnly = true)를 설정하고 메소드 별로 false를 설정하는게 실수를 줄이기 더 좋고 간편함. 하지만 적절히 잘 활용
• 당연한 얘기지만 중복 체크의 경우 multi instance에서 안전하지 않은 경우가 있음. DB Level에서의 중복체크(unique)등이 꼭 필요

test code 작성

• test code에서의 transactional은 commit이 아니라 rollback을 하기때문에 실제 insert가 일어나지 않음. 테스트가 필요한 경우 @Rollback(false)로 명시적으로 지정해줘야 함
• 강의 내용에는 없지만 junit 5에서는 @Test의 exptect 옵션이 없어짐. Assertions.assertThrows를 활용해서 명시적으로 Exception을 assert해줘야 함.
• test code를 실행할 때 test/resources가 존재 할 경우 우선순위가 더 높게 설정됨.
• h2 starter가 존재하는 경우 별도의 설정이 없으면 in-memory db가 실행되게 됨. sandbox구성이 간편해짐.

엔티티 상태 변경

• 엔티티의 상태 변경을 수행하는 기능은 엔티티 내부에 존재하는게 oop적으로도 좋음.(응집도 향상)
• 무분별한 setter로 인해서 변경 포인트가 많아지면 추적하기도 힘들고 디자인 적으로도 응집도가 낮아진다.