본문 바로가기

Spring

용어 정리

@Controller

  • 요청을 받아서 view를 리턴

@RestController

  • @Controller에 @ResponseBody가 포함되어 있다.

@ResponseBody

  • view가 아닌 json 데이터를 클라이언트에 보낸다

@RequestMapping

  • 요청과 컨트롤러 메서드를 맵핑하기 위한 애너테이션
  • @GetMapping 등을 사용해서 좀 더 편하게 사용할 수 있다.

@RequestBody

  • 컨트롤러로 전송된 정보가 자동으로 Map으로 변환되어 해당 변수에 저장된다.
  • json으로 데이터가 넘어오는 post 요청에 객체로 맵핑할 때 주로 사용된다.

@RequestParam

@PathVariable

@ModelAttribute

  • @ModelAttribute가 붙은 객체는 HTTP로 넘어온 값들을 자동으로 바인딩한다.
  • 바인딩된 객체는 자동으로 Model 객체에 추가되고 뷰단까지 전달이 된다.

ResponseEntity

  • @ResponseBody와 기능적으론 같지만, 그 구현 방법이 다르다.
  • 일반적인 API는 반환하는 리소스에 Value만 있지 않다.
  • 상태코드, 응답 메세지 등이 포함될 수 있는 데 그럴 때 사용된다.
  • spring framework에서 제공하는 HttpEntity를 상속받음으로써 HttpHeader와 body를 가질 수 있다.
  • Header 값을 통해 조금 더 견고한 API를 개발하고 싶을 때 사용하자.

RESTful이란?

  • REST는 Representational State Transfer라는 용어의 약자로서 웹의 장점을 최대한 활용할 수 있는 아키텍처
  • 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
  • REST 아키텍처는 Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

DI(Dependency Injection)

  • 의존성 주입

DIP(Dependency Inversion Principle)

  • 의존 역전 원칙, 변하기 쉬운 클래스에 의존하지 않는 것

IOC(Inversion Of Control)

  • 제어의 역전

DTO(Data Transfer Object)

  • 계층간 데이터 교환을 위한 객체
  • DB에서 데이터를 얻어 Service나 Controller 등으터 보낼 때 사용하는 객체
  • 로직을 갖고있지 않은 순수한 데이터 객체, getter/setter만 가진다.
  • setter를 활용하기 보단 생성자를 통해 값을 변경한다.
  • Domain Model을 아무리 잘 설계했다고 해도 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있다. 이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 된다. 또한 Domain Model을 복잡하게 조합한 형태의 Presentation 요구사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어렵다.
  • 즉 DTO는 Domain Model을 복사한 형태로, 다양한 View를 각각 DTO에 각자의 Presentation Logic을 생성자에 추가한 정도로 사용하며 Domain Model 객체는 Persistent(지속성)만을 위해서 사용한다.

Entity

  • 식별성을 가져야 한다.
  • 동일하다는 것이 무엇을 의미하는지 정의해야 한다.
  • 실제 DB테이블과 매칭될 클래스
  • 최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현한다.
    • 단, Domain Logic만 가지고 있어야 하고 Presentation Logic을 가지고 있어서는 안된다.
    • 여기서 구현한 method는 주로 Service Layer에서 사용한다.

DTO와 Entity를 분리하는 이유

  • View Layer와 DB Layer의 역할을 철저히 분리하기 위해
  • View와 통신하는 DTO는 자주 분리되기 때문에 분리해야 한다.

@RequiredArgsConstructor

  • 초기화 되지 않은 final 필드와 @NonNull 어노테이션이 붙은 필드에 대한 생성자 생성
  • 생성자 없이 생성자 의존성 주입이 가능한 Lombok 어노테이션.
  • 단점
    • 처음 보는 사람이라면 잘 이해가 안갈 수 있다.
    • 상속 받은 클래스에서는 적용이 안된다.
    • 인터페이스를 구현(implements)하는 경우에는 가능하다.
    • @Value 값으로 사용하려고 하는 경우 실수로 Bean으로 주입을 받으려는 현상을 겪을 수 있다.

@postConstruct

  • 객체의 초기화 부분
  • 객체가 생성된 후 별도의 초기화 작업을 위해 실행하는 메소드를 선언한다.
  • @PostConstruct 어노테이션을 설정해놓은 init 메소드는 WAS가 띄워질 때 실행된다.

@PreDestory

  • 마지막 소멸 단계
  • 스프링 컨테이너에서 객체(빈)를 제거하기 전에 해야할 작업이 있다면 메소드위에 사용하는 어노테이션.
  • close() 하기 직전에 실행 -> ((AbstractApplicationContext) context).close()

RestAssured TypeRef

.extract().as(new TypeRef<CustomResponse<Boolean>>()

제네릭 정보는 런타임에 들어가면 사라지기 때문에 CustomResponse로 as를 할 수 없다. 이럴 때를 위해 TypeRef로 형을 강제해줄 수 있다.

'Spring' 카테고리의 다른 글

@Mock vs @MockBean  (0) 2020.08.14
MockMvc VS RestAssured  (0) 2020.08.14
Tacademy JPA 강의 정리  (1) 2020.07.01
Web server failed to start. Port 8080 was already in use 에러  (9) 2019.11.07
Mybatis, Invalid bound statement (not found) 에러  (0) 2019.11.05