Annotation 정리

2022-06-26

​

1. Entity

- Entity는 JPA의 어노테이션이며, @Getter, @NoArgsConstrucotr는 롬복의 어노테이션

- 롬복은 코드를 단수화시켜 주지면 필수 어노테이션은 아님

- 그래서 주요 어노테이션 @Entity를 클래스에 가깝게 두고 롬복 어노테이션을 위로

- 이렇게 하면 이후에 코틀린 등의 새 언어 전ㄹ환으로 롬복이 더이상 필요 없을 경우 쉽게 삭제 가능

- Posts 클래스는 보통 Entity 클래스라고도 함

- Entity 클래스를 Request/Response 클래스로 사용해서는 안됨

그리고 꼭 Entity 클래스와 Controller에서 쓸 DTo는 분리해서 사용​

그리고 View Layer와 db Layer의 역할 분리를 철저하게 하는게 좋음

​

@Entity

- 테이블과 링크될 클래스임을 나타냅니다.

- 기본값으로 클래스의 카멜케이스 이름을 언더스코어 네이밍(_)으로 테이블 이름을 매칭

EX) SalesManager.java -> slaes_manager table

​

2. @ Id

- 해당 테이블의 PK 필드를 나타냅니다.

​

3. @GeneratedValue

- PK의 생성 규칙을 나타냅니다.

- 스프링 부트 2.0 에서는 GenerationType.IDENTIIY 옵션을 추가해야만 auto_increment가 됨

​

4. @Column

- 테이블의 칼럼을 나타내며 굳이 선언하지 않더라고 해당 클래스의 필드는 모두 칼럼

- 사용하는 이유는, 기본값 외에 추가로 변경이 필요할때, 문자열의 결우 Varchar(255)가 기본값

​

참고

- 웬만하면 Entity의 PK는 Long 타입의 Auto_incrementㄹㄹ 추천

- 주민등록번호와 같이 비즈니스상 유니크 키나, 여러키를 조합한 복합키로 PK를 잡을 경우 난간함 상황 종종 발생

1) FK를 맺을 때 다른 테이블에서 복합키 전부를 갖고 있거나, 중간 테이블을 하나 더 둬야 하는 상황이 발생

2) 인덱스에 좋은 영향을 끼치지 못합니다.

3) 유니크한 조건이 변경될 경우 PK 전체를 수정해야 하는 일이 밠ㅇ

- 주민등록번호, 복합키 등은 유니크 키로 별도로 추가하시는것을 추천 *

​

5. @ NoArgsConstructor

- 기본 생성자 자동 추가

- public Posts(){}와 같은 효과

​

6. @Getter

- 클래스 내 모든 필드의 Getter 메소드를 자동 생성

​

7. @Builder

- 해당 클래스의 빌더 패턴 클래스를 생성

- 생성자 상단 선언 시 생성자에 포함된 필드만 빌더에 포함함\

- Setter 메소드가 없는데, 언제 어디서 변해야하는지 코드상으로 명확하게 구분할 수가 없어, 차후 기능 변경 시 복잡

그래서 절대 생성 X

​

8. RequiredArgsConsturctor

- 선언된 모든 final 필드가 포함된 생서자를 생성해 줍니다.

- final이 없는 필드는 생성자에 포함되지 않습니다.

- final 선언된 모든 필드를 인자값으로 하는 생성자 롬복을 대신 생성

-> 생성자를 직접 안쓰고 롬복 어노테이션을 사용하는 이유는 해당 클래스의 의존성 관계가 변경될 떄마다 생성자 코드를 계쏙해서 수정해야하는 번거러움을 해소하기 위해

​

9. RestController

- 컨트롤러를 JSON을 반환하는 컨트롤러로 만들어 줍니다.

- 예전에는 @ResponseBody를 각 메소드마다 선언했던 것을 한번에 사용할 수 있게 해준다고 생각

​

10. GetMapping

- HTTP Method인 Get의 요청을 받을 수 있는 API를 만들어 줍니다.

​

11. @RequestParam

- 외부에서 API로 넘긴 파라미터를 가져오는 어노테이션

- 여기서는 외부에서 name 이란 이름으로 넘긴 파라미터를 메소드 파라미터 name에 저장하게 됨.

​

​

12. After

- Junit* */에서 단테가 끝날 때마다 수행되는 메소드를 지정

- 보통은 배포 전 전체 테스트를 수행할 때 테스트간 데이터 침범을 막기 위해 사용

- 여러 테스트가 통시에 수행되면 테스트용 DB인 H2에 데이터가 그대로 남아 있어 다음 테스트 실행시 실패 할 수 ㅣㅇ씅ㅁ

​

13. postsRepository.save

- 테이블에 posts에 insert/update 쿼리를 실행

- id 값이 있따면 update, 없으면 insert

​

14. findAll

- 테이블 posts에 있는 모든 데이터를 조회해오는 메소드

​

15. @SpringBootTest

- 사용할 경우 H2 DB를 자동으로 실행해줌

​

16. AssertThat

- assertj라는 테스트 검증 라이브러리의 검증 메소드

- 검증하고 싶은 대상을 메소드 인자로 받습니다.

- 메소드 체이닝이 지원되어 isEquaTo와 같이 메소드를 이어서 사용할 수 있습니다.

​

* Junit과 비교하여 assertj의 장점

1. CoreMatchers와 달리 추가적으로 라이브러리가 필요하 지 않습니다.

- Junit의 assertThat을 쓰게 되면 is()와 같이 CoreMathcers 라이브러리가 필요합니다.

2. 자동완성이 좀 더 확실하게 지원됩니다.

- IDE에서는 CoreMatchers와 같은 matcher 라이브러리의 자동완성 지원이 약합니다.

​

17. @RunWith(SpringRunner.class)

- 테스트를 진행할 때 JUnit에 내장된 실행자 외에 다른ㅅ 맇애자를 실행시킵니다.

- 여기서는 SpringRunner라는 스프링 실행자를 사용합니다.

- 즉 스프링 부트 테스트와 Junit 사이에 연결자 역할을 합니다.

​

18. @WebMvcTest

- 여러 스프링 테스트 어노테이션 중, Web(Spring MVC)에 집중할 수 있는 어노테이션 입니다.

- 선언할 경우 @COntroller, @ControllerAdvice 등을 사용할 수 있습니다.

- 단 @Service, @Component, @Repository 등은 사용할 수 없습니다.

- 여기서는 컨트롤러만 사용하기 떄문에 선언

​

19. @ Autuwired

- 스프링이 관리하는 빈(Bean)을 주입 받습니다.

​

20. private MockMvc mvc

- 웹 API를 테스트할 때 사용합니다.

- 스프링 MVC 테스트의 시작점입니다.

- 이 클래스를 통해 HTTP GET, POST등에 대한 API 테스트를 할 수 있습니다.

​

21. mvc.perform(get("/hello"))

- MockMvc를 통해 /hello 주소로 HTTP GET 요청을 합니다.

- 체이닝이 지원되어 아래와 같이 여러 검증 기능을 이어서 선언할 수 있습니다.

​

22 .andEXpect(status().isOk())

- mvc.perform의 결과를 검증

- HTTP Header의 Status를 검증

- 우리가 흔히 알고 있는 200, 404, 500 등의 상태 검증

​

23. param

- API 테스트할 때 사용될 요청 파라미터를 설정

- 단, 값은 String만 허용

- 그래서 숫자/날짜 등의 데이터도 등록할 때는 문자열로 변경해야만 사용 가능

​

24.jsonPath

- JSON 응답값을 필드별로 검증할 수 있는 메소드

- $를 기준으로 필드명을 명시

- 여기서는 name과 amount를 검증하니 $.name, $.amount로 검증