복습
- 기능별 패키지를 처음 접해봄
- 상호 독립적인 테스트를 구현하는 방식에 대해 고민해 봄
회고
- 샐리, 영이와 진행한 3인 페어
- 서로의 피드백을 공유하면서 리팩토링 하는 것이 좋았음
- 하나의 도메인을 만드는데(Line) 필요한 정보가 2개의 테이블에 저장되어 있어(Line&Section), setter가 필요했음
- 구간을 삭제/추가하는 로직이 연결리스트 구현과 비슷하다고 느낌
- Bean Validation을 통한 Controller 단에서의 검증 VS 도메인 안에서의 검증
피드백 공유
- Service에서 Repository에 질의를 한다면 도메인이 나오는게 좋아보임
- Dao 하나로 온전히 도메인을 만들 수 없다면, Repository 클래스를 만들어 그 안에 필요한 Dao를 넣어두고, 온전한 객체를 만들어 반환하게 하는 것은 어떨까 고민해보자~
- 코드상에서 중복을 허용하지 않음을 읽을 수 있어야 함
- 원래는 DB 필드에 unique를 걸어둬서 스키마를 읽어야만 알았음
- findByName, findById 등을 조회하여 저장하는 방식을 구현해볼 것
- 테이블의 키로 단건조회하는 비용은 무시해도 괜찮음
- Optional.orElseThrow() 형식의 도입 추천
- List에 null을 담은 상태로 반환하지 말고, 비어있는 리스트를 반환해줄 것
- 테이블별로 Dao를 만들었다. Line을 전부 다 가져오는 findAll() 메서드를 호출하면 DB를 많이 찌르게 된다 괜찮은가? Table Join하여 많이 긁어오는게 좋아보이기도 한다
- DB 접근 시 주로 문제가 되는건 잘못된 실행 계획으로 인한 쿼리 수행시간
- 잘못된 인덱스, 옵티마이저의 부적절한 선택
- Key로 조회하는 것은 효율 측면에서 매우 미비함
- 이 정도는 추후에 문제가 생겼을 때 리팩토링해도 괜찮다
- 데이터 접근 기술을 명시적으로 메서드에 드러내지 말 것 (확장에 안좋음)
- 순환 참조가 아니라면 서비스가 서비스를 가지는 것은 괜찮다
- StationService가 역을 삭제할 때, 해당 역이 들어있는 구간을 삭제해주기 위해 LineService 호출
개선 방향
- 기능별 > 레이여 별로 패키지 좀 분리하자
- Controller의 Request를 다 분해해서 필드를 추출해서 Service한테 넘겼네?
- 그냥 Request를 통으로 Service한테 넘겨주는 건 별로일려나?
- 서비스가 Request까지 알아야할까? Presentation Layer 소속의 객체인데 여기서 쇼부보는게 맞지 않나?
- 필요한 정보를 추출한다는 측면에서 Service가 아는게 어색한가?
- 주구장창 JdbcTemplate만 썼네...
- SimpleInsert 이런 것도 한번 도입 고민해보자