UMC-Inha · meoraeng · Nov 22, 2024 · Nov 22, 2024 · Nov 24, 2024 · Nov 29, 2024
diff --git a/.DS_Store b/.DS_Store
diff --git a/keyword/.DS_Store b/keyword/.DS_Store
diff --git a/keyword/chapter07/keyword.md b/keyword/chapter07/keyword.md
@@ -5,7 +5,7 @@
 - `@AllArgsConstructor`: 모든 필드를 파라미터로 받는 생성자 자동으로 생성
 - `@JsonPropertyOrder`: JSON 직렬화 시 필드의 출력 순서를 지정
 - `@JsonInclude(JsonInclude.Include.NOT_NULL)`: null인 필드를 JSON에 포함하지 않도록 한다 
-
+- `RequiredArgumentConstructor`: (가장 많이쓴다)final
 
 ### Builder
 builder(): (복습)빌더패턴 구현 메서드, 클래스에 대한 빌더 인스턴스를 반환하여 유연하게 객체를 생성할 수 있게 한다.
@@ -36,4 +36,11 @@ vaildation(유효성검증): 데이터가 특정 조건을 만족하는지 확
 
 작동방식 : 컴파일 시 바이트코드를 조작하여 자동으로 메서드를 추가하는 방식이기 때문에 실제 코드 파일에는 나타나지 않고, 컴파일된 클래스 파일에 생성된다.
 
-첫줄에서 정리해둔 어노테이션의 대부분이 Lombok 라이브러리에 속한다.
+첫줄에서 정리해둔 어노테이션의 대부분이 Lombok 라이브러리에 속한다.
+
+
+`public ApiResponse<TempResponse.TempTestDTO> testAPI(){`
+
+응답 DTO를 ApiResponse로 감싸서 전달
+
+컨버터의 역할: 데이터를 다른 형식의 객체로 변환하여 반환, 엔티티를 컴퓨터가 원하는 DTO로 바꿔주려고 사용한다.
diff --git a/keyword/chapter08/keyword.md b/keyword/chapter08/keyword.md
@@ -0,0 +1,60 @@
+### 내용 정리
+
+- converter: 타입 변환, 데이터 바인딩, 서비스 계층에서 DTO와 엔티티간 변환을 위해 활용
+
+- collect 메서드 : Java Stream 종료 연산중 하나
+    - 스트림의 모든 요소를 특정 컬렉션 형태로 수집할떄 사용(ex.`List`)
+- `Collectors.toList()`:
+    - Collectors 클래스의 static method
+    - 스트림의 요소를 List로 수집하는데 사용
+    - 변환된 객체들을 새로운 `List<type>`로 모은다.
+- `stream()`: Java컬렉션(ex.`List`)에 사용할 수 있는 메서드로, 해당 컬렉션의 데이터를 기반으로 Stream 객체를 생성한다
+    - 단순히 데이터를 담고있는 컨테이너가 아니라, 데이터 처리 파이프라인을 설정하는 도구
+    - 스트림 내부에 데이터가 직접 저장되지 않음, 컬렉션의 데이터가 스트림 파이프라인을 통해 필터링, 변환, 수집
+    - 데이터를 간결하고 효율적으로 처리할 수 있음
+- `@Transactional`: 스프링에서 데이터베이스 트랜잭션을 관리하기 위한 설정을 제공한다. 여러 데이터베이스 작업을 하나의 논리적 단위로 처리하기 위해 사용된다.
+    - 트랜잭션 시작과 종료를 관리한다.
+    - 예외 발생 시 롤백한다
+    - 트랜잭션 간의 격리 수준을 설정할 수 있다
+
+- Swagger 세팅
+    - `@Configuration` 어노테이션(설정 클래스 명시)과 `@Bean`어노테이션(구성객체 반환) 사용
+    - `new Info()` : Swagger UI 상단에 표시될 API 제목, 설명, 버전 정의
+    - `SecurityRequirement`: API요청에 보안 요구사항 정의 - 이번엔 JWT 인증 토큰을 API요청시 헤더에 포함하도록 함
+    - `Component` 객체: Swagger 문서에서 사용할 다양한 보안 구성 및 재사용 가능한 객체 정의 -> JWT 인증 스키마 설정(타입, 스키마, 포맷)
+    - `OpenAPI`객체 : Swagger 전체 구성을 정의
+        - `addServersItem`: 기본 URL 설정
+        - `addSecurityItem`: API가 요구하는 보안 설정을 추가. JWT 토큰 인증을 요구하도록 설정.
+        - `components`: 위에서 정의한 보안스키마와 기타 재사용 가능한 설정들을 포함
+
+
+### 키워드 정리
+
+### Java의 Exception 종류들
+1. Checked Exception
+컴파일 시점에 반드시 처리해야 하는 예외로, try-catch 또는 throws를 통해 예외 처리가 강제
+데이터베이스 작업이나 파일 입출력 시 자주 발생
+예시: IOException, SQLException.
+2. Unchecked Exception
+런타임 시점에 발생하며, 처리하지 않아도 컴파일은 정상적으로 된다.
+주로 프로그래밍 실수로 인해 발생하며, Null 처리와 같은 상황에서 자주 나타난다.
+예시: NullPointerException, IndexOutOfBoundsException.
+3. Error
+시스템 레벨에서 발생하는 문제로, 일반적으로 개발자가 처리할 수 없는 경우이며
+메모리 부족이나 스택 오버플로와 같은 상황에서 발생한다.
+예시: OutOfMemoryError, StackOverflowError.
+4. Custom Exception
+애플리케이션 로직에 따라 개발자가 정의한 예외 클래스
+Exception이나 RuntimeException을 상속받아 구현하며, 특정 상황을 명확하게 처리 가능
+
+### @Valid
+1. @Valid의 역할
+@Valid는 스프링에서 객체의 유효성을 검증하기 위해 사용하는 어노테이션
+입력 데이터가 유효한지 자동으로 확인하며, 주로 Controller에서 요청 데이터 검증에 사용된다
+2. 유효성 검증 기본 원리
+@Valid는 Bean Validation API(JSR 380)를 기반으로 동작한다
+유효성 규칙이 위반되면 예외(MethodArgumentNotValidException)가 발생한다
+3. 주요 유효성 검증 어노테이션
+@NotNull, @Size, @Pattern, @Email, @Min, @Max 등을 사용하여 필드 조건을 명시한다
+4. Custom Validation
+@Constraint와 ConstraintValidator를 사용하여 커스텀 검증 규칙을 구현할 수 있다.
diff --git a/keyword/chapter09/keyword.md b/keyword/chapter09/keyword.md
@@ -0,0 +1,68 @@
+스터디 질문 내용
+워크북 내용중
+> API 하나를 모두 완성 후 명세를 하게 되면 프론트엔드 개발자는 해당 API가 완성이 될 때 까지 다른 API의 응답을 모르기 때문에 작업을 멈추게 됩니다. 이런 상황을 최대한 막기 위해 우선적으로 응답 Data의 형태를 알려주어 프론트 개발자도 미리 API 연결 부분을 작업 해둬 최대한 개발을 **병렬적으로** 할 수 있도록 합니다.
+
+라는 부분이 있는데, 지난 플젝 기준으로 API 기능 개발이 전체적으로 끝나고 서버 호스팅을 마친 뒤에야 연결 작업을 진행했었는데, 배포 하기 전에도 미리 Swagger로 공유를 하는지? 그러면 프론트 측에서 스프링 코드를 클론받아서 실행시키고 보면서 작업해야하는건가
+
+### Swagger 기능
+- `@Operation` : API에대한 설명을 넣을 수 있다. summary, description으로 설명을 적는다.
+- `@ApiResponse` : API의 응답을 담게되며 내부적으로 @ApiResponse로 각각의 응답들을 담게된다.
+- `@Parameters` : 프론트엔드에서 넘겨줘야 할 정보를 담으며, path variable, query String 등등 기재할 수 있음
+
+
+## 키워드 정리
+### Spring Data JPA의 Paging
+Spring Data JPA는 대용량 데이터를 효율적으로 관리하기 위해 페이징(Paging) 기능을 제공
+
+페이징은 데이터의 특정 범위를 나누어 조회하는 기능으로, 두 가지 대표적인 인터페이스를 제공한다. 
+
+Page
+- `Page`는 페이징 처리된 데이터와 함께 전체 데이터에 대한 메타정보를 제공한다 (ex. 전체 페이지 수, 전체 요소 수 등)
+- 메타정보를 함께 가져오기 때문에 약간의 추가 쿼리가 실행된다.
+```Java
+Pageable pageable = PageRequest.of(0, 10); // 페이지 번호와 페이지 크기 지정
+Page<MyEntity> page = myEntityRepository.findAll(pageable);
+
+System.out.println("전체 페이지 수: " + page.getTotalPages());
+System.out.println("전체 요소 수: " + page.getTotalElements());
+System.out.println("현재 페이지 번호: " + page.getNumber());
+System.out.println("현재 페이지 데이터: " + page.getContent());
+
+```
+- 장점: 
+    - 전체 데이터의 크기를 구할 수 있다.
+    - 페이지 이동 기능을 구현하기 용이하다.
+- 단점:
+    - `COUNT`쿼리가 추가적으로 실행된다.
+
+Slice
+- `Slice`는 현재 페이지에 대한 데이터와 다음 페이지의 존재 여부만 제공된다.
+- 전체 페이지 수나 전체 요소 수를 구하지 않으므로 `COUNT`쿼리가 실행되지 않아 성능상 이점이 있다.
+```Java
+Pageable pageable = PageRequest.of(0, 10); // 페이지 번호와 페이지 크기 지정
+Slice<MyEntity> slice = myEntityRepository.findAll(pageable);
+
+System.out.println("현재 페이지 데이터: " + slice.getContent());
+System.out.println("다음 페이지 존재 여부: " + slice.hasNext());
+
+```
+
+- 장점
+    - 필요한 데이터만 조회하여 성능이 더 효율적이다
+    - 다음 페이지 존재 여부만 확인하면 되는 무한 스크롤(인피니트 스크롤) 구현에 적합하다
+- 단점
+    - 전체 데이터의 크기를 알 수 없다
+### 객체그래프 탐색 처리
+Spirng Data JPA는 엔티티를 효율적으로 로드하기 위한 객체 그래프 탐색 전략을 제공한다. 대표적으로 지연로딩과 즉시로딩 전략이다. 
+
+- 지연 로딩
+    - 연관된 엔티티를 실제 사용 시점에 로드
+    - `@OneToMany`, `@ManyToOne` 관계에서 기본적으로 사용됨
+    - 데이터베이스 쿼리가 필요할 떄만 실행되므로 초기 로드 시 성능이 좋음
+- 즉시 로딩
+    - 연관된 엔티티를 즉시 로드
+    - 연관 엔티티를 자주 사용하는 경우 적합
+- Fetch Join
+    - 객체 그래프를 탐색할 때 JPA의 Fetch Join을 사용하면 N+1문제를 방지할 수 있음
+    - 연관된 엔티티를 한번의 쿼리로 가져온다
+
diff --git a/mission/.DS_Store b/mission/.DS_Store
diff --git a/mission/chapter06/mission.pdf b/mission/chapter06/mission.pdf
diff --git a/mission/chapter07/mission.md b/mission/chapter07/mission.md
@@ -0,0 +1,30 @@
+ApiResponse - 통일된 API 응답을 위한
+![alt text](image-9.png)
+
+에러 형식 DTO
+![alt text](image-7.png)
+![alt text](image-8.png)
+에러 상태 enum
+![alt text](image-5.png)
+성공 상태 enum
+![alt text](image-6.png)
+서비스
+![alt text](image-2.png)
+![alt text](image-13.png)
+컨트롤러
+![alt text](image-3.png)
+컨버터
+![alt text](image-12.png)
+응답 DTO
+![alt text](image-4.png)
+핸들러
+![alt text](image-10.png)
+ExceptionAdvice - `@RestControllerAdvice`를 예외처리에 적용
+![alt text](image-11.png)
+
+
+`/temp/test` 경로 실행 결과:
+![alt text](image.png)
+
+`/temp/exception?flag` 실행결과:
+![alt text](image-1.png)
diff --git a/mission/chapter07/mission.pdf b/mission/chapter07/mission.pdf
diff --git a/mission/chapter08/image-1.png b/mission/chapter08/image-1.png
diff --git a/mission/chapter08/image-2.png b/mission/chapter08/image-2.png
diff --git a/mission/chapter08/image-3.png b/mission/chapter08/image-3.png
diff --git a/mission/chapter08/image-4.png b/mission/chapter08/image-4.png
diff --git a/mission/chapter08/image-5.png b/mission/chapter08/image-5.png
diff --git a/mission/chapter08/image-6.png b/mission/chapter08/image-6.png
diff --git a/mission/chapter08/image.png b/mission/chapter08/image.png
diff --git a/mission/chapter08/mission.md b/mission/chapter08/mission.md
@@ -0,0 +1,16 @@
+실습
+---
+![alt text](image.png)
+![alt text](image-1.png)
+![alt text](image-2.png)
+
+미션
+---
+작업 순서 : DTO 생성 -> 컨버터 생성 -> 컨트롤러 생성 -> 서비스 생성 -> 리포지토리 생성 (선택) -> FK 리포지토리 구현 및 서비스 완성, 컨트롤러 완성
+1. 가게 추가하기 API
+![alt text](image-3.png)
+![alt text](image-4.png)
+
+2. 가게에 리뷰 추가하기 API
+![alt text](image-5.png)
+![alt text](image-6.png)
diff --git a/mission/chapter09/image-1.png b/mission/chapter09/image-1.png
diff --git a/mission/chapter09/image.png b/mission/chapter09/image.png
diff --git a/mission/chapter09/mission.md b/mission/chapter09/mission.md
@@ -0,0 +1,8 @@
+### 실습 결과
+![alt text](image.png)
+
+
+### 미션 내용
+1. 유저가 작성한 리뷰 리스트
+![alt text](image-1.png)
+기존 가게 id로 검색하는 컨트롤러와 경로가 동일하면 충돌이 일어나기에, 두 컨트롤러 경로의 앞에 각각 store, member를 추가로 작성해주었다.