Search
스프링에서 만일 @Controller 어노테이션이 붙은 클래스에서 예외가 발생하면 어떤 일이 발생할까?
아래와 같이 500에러가 난다.
이는 SpringBoot의 기본 에러 처리 컨트롤러인 BasicErrorController 로 처리된 결과다. 여기서 ErrorAttribute 라는 값을 이용해 500에러와 함께 뜨는 responseBody 를 생성한다.
Spring의 BasicErrorController
2024/04/20
DIARY
happy case만 처리하고 전부 status code로 200을 뱉을 때, 아래 4개의 코드는 같은 결과를 낸다.
Controller vs RestController
우선 1,2번보단 3,4번을 사용하는 편이 현재 코드의 의도를 더 명확히 드러낼 수 있다 생각한다.
Restful한 웹 서비스를 생성할 거라는걸 이름만으로도 표현해주기 때문이다. 참고
Spring 4.0 introduced the @RestController annotation in order to simplify the creation of RESTful web services
ResponseBody vs ResponseEntity
다음으로 3번보단 4번을 사용하는 편이 추상화 관점에서 더 바람직하다 생각한다.
추상화 레벨을 통일하는 데 도움이 되기 때문이다.
ResponseBody, ResponseEntity, RestController 사용과 추상화
2024/04/19
DIARY
아래 코드에 대해 Dao인데 Repository 어노테이션을 사용한 이유에 대해 질문 받았다.
일단 왜 위의 코드가 Dao인지부터 궁금할 수 있는데, 추후 save, delete, find 동작이 List 콜렉션에 대해 동작하는 게 아니라 database에 대해 동작하게 리팩토링할 계획이라 Dao라고 이름 붙여뒀다.
Repository 어노테이션의 역할
스프링 빈으로 등록하고 싶어서 별 고민없이 사용했었는데, @Repository 어노테이션의 역할을 살펴보니 현재 코드에선 불필요하단 점을 깨달아 @Component 어노테이션으로 변경해주었다. 현재 코드에선 database와 관련한 예외를 변환할 일이 없기 때문이다. 스프링 빈으로 등록시키는 건 @Component 어노테이션으로 충분하다.
•
@Repository 의 역할
Dao와 Repository 어노테이션 (with 공식문서)
다만, 후에 database를 적용한다면 Dao여도 @Repository을 붙이는 게 말이 아예 안되진 않을 거 같다.
공식문서를 찾아보니 아래와 같이 명시하고 있다.
Teams implementing traditional Jakarta EE patterns such as "Data Access Object" may also apply this stereotype to DAO classes, though care should be taken to understand the distinction between Data Access Object and DDD-style repositories before doing so. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use as appropriate.
Dao 클래스에 Repository 어노테이션을 붙여도 될까
2024/04/17
DIARY
우테코 미션을 하다보면, 추상클래스를 쓸 때도 있고 인터페이스를 쓸 때도 있다. 둘의 차이를 내 생각과 함께 면밀히 정리해보겠다. 용어 정의에 바탕한 이론을 다루는 글임을 미리 밝힌다. 학창 시절 교수님께 배웠던 C++의 추상클래스와 비교하며 원론적인 정의를 내려보겠다.
1. Dynamic Method Dispatch (vs. Dynamic Binding)
먼저, Dynamic Method Dispatch 라는 개념을 통해 추상 이란 용어에 대해 이해해보자. 긴 용어로 들으면 뭐지 싶을 수 있는데, 해석해보면 어렵지 않다. “동적으로 호출할 메서드를 결정한다”라는 뜻이다. 반댓말론 Static Method Dispatch 가 있다. 이는 “정적으로 호출할 메서드를 결정한다”라는 뜻이다.
정적이라 함은 컴파일 시점에 컴파일러가 특정 메서드를 호출할 것을 명확히 알고 있는 경우를 의미하고, 동적이라 함은 컴파일러는 어떤 메서드를 호출해야 하는 지 모르고 런타임 시점에 호출할 메서드를 결정하는 경우를 의미한다.
그렇다면 어떻게 해야 동적으로 메서드 호출을 결정할 수 있을까? 바로, 인터페이스나 추상 클래스에 정의된 추상 메서드를 사용하면 된다. 같은 클래스를 상속하고 있는 여러 클래스 중 어느 서브 클래스를 사용할 것인가를 런타임 시점까지 미룸으로서, 클래스 재사용성을 높이는 것이다.
여기까지 읽고 나면 이거 Dynamic Binding 이랑 완전 똑같은 거 아니야? 싶을 수 있다. 허나, Dynamic Method Dispatch 와 Dynamic Binding 은 엄밀히 말하자면 다른 개념이다. 아래 링크로 들어가보면 깔끔하게 이를 정의내려주는데, 요약하자면 Dynamic Binding은 런타임 시점에 특정 메서드 구현을 결정하는 메커니즘이고, Dynamic Method Dispatch는 Dynamic Binding을 사용해 런타임 시점에 특정 메서드 구현을 결정하고 이를 찾아 호출하는 과정까지를 포함한다고 한다.
Dynamic dispatch is different from late binding (also known as dynamic binding). Name binding associates a name with an operation. A polymorphic operation has several implementations, all associated with the same name. Bindings can be made at compile time or (with late binding) at run time. With dynamic dispatch, one particular implementation of an operation is chosen at run time. While dynamic dispatch does not imply late binding, late binding does imply dynamic dispatch, since the implementation of a late-bound operation is not known until run time.
Dynamic Binding(==late binding)과 Dtnamic Method Dispatch의 차이에 대해 더 자세히 알고 싶은 사람은 아래 글도 추천한다.
Abstract class vs Interface (virtual function vs abstract method)
2024/03/25
JAVA
Load more