Spring MVC/API 계층

Spring MVC를 이용하여 API 계층의 Controller 클래스를 구현하는 연습을 하고있다.

Client의 요청을 처리하는 Controller 클래스의 Handler매서드들을 Spring MVC의 어노테이션을 이용하여 만들고 요청받은 혹은 전달받은 데이터들을 Mapping할때 편의와 유지보수를 위해, 또 Validation을 쉽게 추가하기위해 데이터를 객체로 받는 방식인 Dto(Data Transfer Object)를 적용하면서 스프링이 지원하는 엄청난 편의성들에 감탄하고 하루하루 재밌게 즐기고있다.

오늘 Dto클래스들을 구현하면서 저지를 사소한 실수들과 깨달은점, 그리고 남은 의문점 몇가지들을 기술하려한다.

1. Validation

• 실수: @PathVariable을 통해 받은 파라미터에 대한 Validation조건의 적용 위치
  • @Positive로 path로 받은 Id값을 양수로 한정하는것이 목표였다.
    처음에 다른 조건들과 마찮가지로 RequestBody부분에 @Positive를 적용하였으니 아무리 양수의 아이디값을 넣어도 오류메세지를 리스폰스 하였다!
  • 이를 해결하기 위해 많은 시도를 했는데, 그첫번째가 Id의 타입인 long을 Wrapper Class, Long 타입으로 바꿔보는 것 이었다. 하지만 실패...
  • 다양한 방법을 시도하다가 문득 @Postitive를 검사하는 위치에 대한 의문이 생겼고 그 위치를 @PathVariable 어노테이션을 받는 곳으로 이동시켰더니 성공!
    

의문점.. : 어차피 같은 long타입이 setCoffeeId()를 통해 초기화 될텐데 그때 검사가 되어도 상관이 없을거라 생각했는데 그렇지 않았다. 이유가 궁굼하다. 더 파헤쳐 봐야 할 듯 하다.

또한 Valid 조건들을 적용하면서 잘 적용한듯 하였는데 몇가지 잘 풀리지 않았던 부분들이 있었다.

• 두가지의 상반되는 Validation을 같이 적용할때

  • @Nullable은 null 값을 허용하고 @Min은 100이상만을 허용하는데 이때 해당 필드의 타입을 int, premitive 타입으로 지정했을때 두가지가 동시에 적용되지 않았다. null 값을 100이상이 아니라고 인식하기 때문이였다.

    ---> @Nullable은 RequestBody의 Validation으로 쓰이지 않고 파라미터의 Null값 허용 여부를 명시한다.(Jun.13th.2023)

  • 다양한 시도 끝에 필드의 타입을 primitive가 아닌 wrapper 클래스인 Integer로 바꾸면 null값에 대한 적용범위가 다양해져서 가능하지 않을까 생각이 들었고 이는 성공하였다.

    의문점: 정확한 이유를 아직 모르겠다. wrapper 클래스에 대한 이해가 더 필요한것 같다.
    ---> Wrapper 클래스타입으로 바꾸면 레퍼런스값을 갖는 객체가 됨으로 null값을 담을 수 있다. 하지만 int는 불가!(Jun.13th.2023)

    ---

    공부하면서 느낀 추가적인 의문점

  1. 나는 ControllerDto클래스를 만들고 이너클래스로 개별적인 Dto 클래스들을 만들고 사용하면 Dto 클래스들을 관리하기 쉽고 더 편하지 않을까 생각에 이를 적용했는데 이너클래스들을 static클래스로 만들지 않으니 오류가 발생했다. 그리고 반드시 static으로 만들어야 한다는 메세지를 출력했는데 이에 대한 의문이 아직 남아있다.