[우아한테크코스] 5월 8일 TIL
[지하철 노선도 미션] 피드백 리뷰
[Spring] Application Programming Interface
요구사항에는 upStation, downStation과 같은 정보는 포함되어 있지 않다.
인터페이스 스펙 외의 요청을 받고 처리해줄 필요가 있는가?
문서로 제공된 인터페이스와 다른 기능을 제공하는 것에 대해 의구심을 갖도록 하자.
나는 http response를 찍어보고 upStation, downStation 정보를 넘겨주도록 했지만 이게 옳은 것이 아니었던 것이다..!
[Exception] 예외 처리
frontend에서 옳지 않은 정보가 넘어온 경우 예외를 처리하기 때문에 delete, find와 같이 찾은 정보가 없거나, delete할 정보가 없거나, 들어온 정보가 없는 경우 아래와 같이 따로 예외를 처리해주지 않았다.
String은 null으로 충분히 들어올 수 있다. 관련 예외 처리는 필요하다.
- 응답이 null일 경우의 예외 처리
public LineResponse createLine(long upStationId, long downStationId, String lineName, String lineColor) { long lineId = lineDao.save(lineName, lineColor); }
서비스에 넘어온 lineName, lineColor와 같은 변수들이 null이라면 어떻게 처리해줄지 유효성 검증이 필요하다.
방어로직은 백이든 프론트든 가지고 있는 것이 좋다. 돌렸을 때 발생할 수 있는 예외라면 처리해주는 것이 옳다. -
exception의 처리
지금 모든 DataAccessException을 잡아서 badRequest로 반환하고 있다.
이 예외는 과연 사용자의 입력이 잘못됐을 때만 발생하는 것일까?
그렇지 않다. 특정 예외를 처리해주어야하는 곳에서 특정 custom exception을 throw해서 관리하도록 하자.
db에 unique 키를 두어서 중복 처리를 하고 있지만 이러면 자바 코드만으로는 모든 내용을 알 수 없고 ddl까지 알아야 한다.
서비스 레이어에서 예외를 처리하는 것이 옳다. - SQLException 보다는 RuntimeException
예상되는 특정 예외가 아닌 예외들은 500으로 처리하는 것이 좋기 때문에 RuntimeException으로 보다 넓은 범위에서 잡아서 던져주는 것이 좋다.
[Java] 생성자 추가
public void update(long id, String lineName, String lineColor) {
위와 같이 각 정보를 열어서 dao에 넘겨주도록 구현하였는데, 이대로라면 컬럼이 추가되면 관련된 모든 곳에 가서 추가해주는 작업이 필요하다.
뿐만 아니라 생성할 일이 있을 때마다 getter로 모든 값을 꺼내주어야 한다.
이 과정에서 타입이나, 옳지 않은 입력으로 잘못된 값이 전달되지는 않는지 확인해주어야 한다.
확장성을 갖기 위해 Line에 여러 생성자를 두고 아래와 같이 구현하도록 하자.
LineResponse에 정적팩토리 메서드를 지원해주는 방법 또한 있을 수 있다.
public void update(Line line);
[Spring] DTO의 사용 범위
원치는 않았지만 이번 미션에서 Response 객체가 일치해서 모든 곳에서 반환하도록 했다.
휴에게 관련해서 물어보니 DTO는 주로 request, response 위주로 사용하고 Controller에서 Service에 줄 때 도메인으로 변환해서 준다고 하였다. 내가 체스 때 service에서 처리하던 일을 controller에서 하는 것이다.
service의 역할은 무엇일까?
이 외에도 dao와 도메인 객체가 사용하는 값이 다른 경우에도 dto를 전달한다고 하였다.
나는 어떤 방안을 찾아갈까?
[Spring] @Autowired
생성자가 여러 개 있는 경우 스프링은 @Autowired
가 붙은 생성자를 의존성 주입이 일어날 것이라고 생각하고 처리한다.
그게 아니고 bean의 경우는 생성자가 여러 개 나올 수 없으므로 굳이 붙이지 않아도 되지 않다. 라는 의견을 받았다.
[Spring] response*
응답에 List<Station>
과 같은 것이 :null
로 가도 괜찮나? 에 대한 고민이 있었다.
설계에 따라서 필요에 따라 필요한 것을 가진 객체를 주면 null이 필요하지 않음을 알지 못할 수 있다.
null 반환에 대한 의견 참고
List의 경우는 null이 아닌 empty list를 반환하도록 하자.
추가 공부
- @Primary