1. 전체적인 미션의 방향
2. 과제를 진행하면서 배운점
3. 추가적인 공부가 요구되는 사항들
4. 공통 피드백

1. 전체적인 미션의 방향

이번 주차의 미션은 '숫자 야구 게임'을 만드는 것이다. 기본적인 게임의 규칙은 1부터 9까지의 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임이다.(숫자와 자리 수가 같은 경우 - 스트라이크, 숫자만 같고 자리 수가 다른 경우 - 볼)

• 1. 게임에 필요한 '플레이어'와 '상대방'등을 만들어서 객체 지향으로 설계한다.

• 2. 예외를 발생시킨다. (IllegalArgumentException 이용)

• 3. 테스트케이스 작성

  

2. 과제를 진행하면서 배운점

1. 객체 지향 설계

• 숫자 야구 게임을 위해서 'Player', 'Computer(상대방)', 그리고 'Game'으로 객체를 나누었다. 그리고 각각의 역할에 대해서 기능들을 추가하여 객체 지향적으로 개발을 진행하였다.

2. 예외 처리

• 플레이어의 입력에 대해서 예외처리를 하였다. 예를 들어, '서로 다른 세자리 수'를 입력해야 하는 경우에 '2자리 수를 입력하거나', '문자를 입력하거나', '223과 같이 중복된 수를 입력한 경우' 예외 처리를 하였다.

• 그리고 예외가 발생한 경우 즉시 애플리케이션을 종료해야함으로 게임이 시작되는 순간부터 try-catch를 사용하여 예외가 발생한 경우 바로 애플리케이션이 종료되도록 처리하였다.

3. 테스크 케이스 작성

• 'JUnit5'와 '단위 테스트'에 대해서 공부하고 블로그에 글을 올린 경험이 있다. JUnit5를 사용하는 것에는 문제가 없었지만 단위 테스트를 작성하는데 어려움이 있었다. 특히 private가 있는 메서드의 경우 TEST에서 접근을 할 수가 없는 문제가 있었다. (물론 구글링을 해보니 private라도 접근하는 방법이 있었다....)(추후 해당 방법에 대한 글을 작성할 예정이다.) 그래서 접근이 가능한 메서드를 이용하여 최대한 단위 테스트가 가능하도록 테스트를 작성하였다.

3. 공통 피드백

1. 기능 목록을 재검토한다.

• 기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다.
• 클래스 이름, 함수(메서드) 시그니처와 반환값은 언제든지 변경될 수 있기 때문이다.
• 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는데 집중한다.
• 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다.
• 특히 예외 사항은 시작 단게에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

2. 값을 하드 코딩하지 않는다.

• 문자열, 숫자 등의 값을 하드 코딩하지 않는다.
• 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라.
• 구글에서 "java 상수"와 같은 키워드로 검색해 상수 구현 방법을 학습하고 적용해 본다.

3. 구현 순서도 코딩 컨벤션이다.

• 클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.

4. 변수 이름에 자료형은 사용하지 않는다.

• 변수 이름에 자료형, 자료 구조 등을 사용하지 않는다. (ex. carNameList, arrayString 등)

5. 한 함수가 한 가지 기능만 담당하게 한다.

• 함수 길이가 길어진다면 한 함수에서 여러 일을 하려고 하는 경우일 가능성이 높다.
• 예를 들어 한 함수에서 '안내 문구 출력, 사용자 입력, 유효값 검증' 등의 일을 한다면 이를 적절하게 분리해야 한다.

6. 처음부터 큰 단위의 테스트를 만들지 않는다.

• 테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다.
• 시작부터 큰 단우의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다.
• 그래서 문제를 작게 나누고, 그 중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.

4. 추가적인 공부가 요구되는 사항들

1. private로 지정된 메서드의 테스트 방법

2. 함수가 한 가지 기능만 담당하도록 설계 연습을 꾸준히 한다!

1. 전체적인 미션의 방향
2. 과제를 진행하면서 배운점
3. 추가적인 공부가 요구되는 사항들
4. 공통 피드백

1. 전체적인 미션의 방향

'온보딩'이라는 단어에서 알 수 있듯이 4주차까지 미션을 진행하기에 필요한 기본적인 사항들을 배우는 시간이었다. Java Collection 자료구조(List, Set, Map 등)를 사용하면서 7가지 문제를 푸는 방식으로 미션이 진행되었다.

2. 과제를 진행하면서 배운점

1. JAVA 언어 활용

• C++를 사용해서 코딩테스트를 준비할 때에는 다양한 자료구조들을 사용하였는데, JAVA를 통해 프로젝트를 할 때에는 생각보다 다양한 자료구조를 사용하지 못했구나라는 생각을 하였다. 그래서 이번 과제를 통해 JAVA에서 다양한 자료구조를 사용해볼 수 있었다.

2. 네이밍 연습

• '과제 제출'이라는 압박감으로 네이밍에 많은 신경을 썼다.
• 어떻게 하면 더 쉽게 코드를 이해할 수 있을까부터 시작해서 반복문에 있는 값(항상 쓰던 i)까지 모두 고려하여 이름을 부여하였다.

3. 공통 피드백

1. 이름을 통해 의도를 드러낸다.

• 나 자신, 다른 개발자와의 소통을 위해 가장 중요한 활동 중의 하나가 좋은 이름 짓기이다.
• 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

2. 축약하지 않는다.

• 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

3. 공백도 코딩 컨벤션이다.

• 공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다.
• 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

4. 배열 대신 Java Collection을 사용한다.

• Java Collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 API를 사용할 수 있다.

4. 추가적인 공부가 요구되는 사항들

1. 의미 있는 이름을 작성하는 방법 - (변수 이름, 함수(메서드) 이름, 클래스 이름)

2. Java Collection 자료구조의 다양한 API 사용법

1. HTTP 개념
2. 요청과 응답 흐름
3. HTTP Request 구조
4. HTTP Response 구조
5. 추가사항

1. HTTP 개념

• HyperText Transfer Protocol
• HyperText(HTML) 문서를 교환하기 위해 만들어진 Protocol(통신 규약)
• 주로 TCP를 사용하고 HTTP3부터는 UDP를 사용하며 80번 포트를 사용

2. 요청과 응답 흐름

클라이언트와 서버가 HTTP(s)의 규약 아래에 요청과 응답을 주고 받음.

1. 클라이언트(Client)

정보, 자원, 서비스를 사용하는 측 요청을 보내는 측 $\to$ 예시 : 웹브라우저(크롬, 파이어폭스, 사파리 등등)

2. 서버(Server)

정보, 자원, 서비스를 제공하는 측 요청을 받고 응답하는 측 $\to$ 예시 : 웹 서버(아파치 HTTP서버, NGINX, 마이크로소프트 인터넷 정보 서비스(IIS) 등등)

3. HTTP Request 구조

1. Start Line

구조 $\to$ [HTTP Method][Request target][HTTP version] $\to$ 예시) GET / test.html HTTP/1.1

1. HTTP Method : 요청의 의도를 담고 있는 GET, POST, PUT, DELETE 등이 해당함
2. Request target : HTTP Request가 전송되는 목표 주소
3. HTTP version : version에 따라서 Request 메시지 구조나 데이터가 다를 수 있어서 version을 명시해야 함.

2. Headers

해당 Request에 대한 추가 정보를 담고 있는 부분 $\to$ 요청 하려는 서버 호스트 이름, 포트 번호, cookie, authorization

3. Body

HTTP request가 전송하는 데이터를 담고 있는 부분

4. HTTP Response 구조

1. Status Line

구조 $\to$ [HTTP version] [Status Code] [Status Text] $\to$ 예시) HTTP/1.1 200 OK

1. HTTP version
2. Status Code
3. Status Text

2. Headers

Request Headers와 동일 (다만, response에서만 사용되는 header 값들도 존재)

3. Body

Request Body와 일반적으로 동일 (비어있을수도 있음)

5. 추가사항

클라이언트 (웹 브라우저)가 응답을 받은 후 필요한 리소스들을 추가 요청하여 응답을 받는다. $\to$ 예를 들어, 특정 홈페이지에 접속한 경우 자바스크립트, 이미지 파일 등을 추가적으로 요청하여 받음.

이 글은 아래의 사이트 내용을 참고하였습니다. $\to$ https://hahahoho5915.tistory.com/62 $\to$ https://www.youtube.com/watch?v=0jV7xOUcKog&list=PLgXGHBqgT2TvpJ_p9L_yZKPifgdBOzdVH&index=151

1. 단위테스트의 개념 및 필요성
2. 좋은 단위 테스트의 특징
3. TDD 개념 및 절차
4. 기본 방식과의 차이점
5. TDD의 장점과 단점

1. 단위테스트의 개념 및 필요성

1. 단위테스트의 개념

• 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트 (모듈 : 애플리케이션에서 작동하는 하나의 기능 또는 메소드)
• TDD에서 말하는 테스트가 단위테스트

$\to$ 통합테스트 1. 모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하기 위해 수행되는 테스트 2. 통합된 모듈이 올바르게 연계되어 동작하는지 검증하기 위한 테스트

2. 단위 테스트의 필요성

• 통합 테스트를 위해서는 캐시나 DB 등 다른 컴포넌트와 실제 연결이 필요 $\to$ 비용(시간)이 상당히 커짐
• 단위 테스트는 해당 부분만 독립적으로 테스트하기 때문에 리팩토링시 빠르게 문제 확인 가능 $\to$ 단위 테스트는 수시로 빠르게 돌리면서 문제를 파악할 수 있는 장점이 있음.

  2. 좋은 단위 테스트의 특징(FIRST규칙)

  1. FAST

• 좋은 단위 테스트는 실행이 빨라야한다.

2. INDEPENDENT

• 좋은 단위 테스트는 테스트하고자 하는 단위 기능에 집중해야 한다.

3. REPEATABLE

• 좋은 단위 테스트는 반복적으로 수행하더라도 항상 같은 결과를 반환해야 한다.

4. Self-Validating

• 좋은 단위 테스트는 기대하는 결과가 무엇인지 단언(assert)해야 한다.
• System.out.println과 log.info를 이용하는 것이 아닌 Junit에서 재공하는 assert와 같은 검증 코드를 이용

5. Timely

• 좋은 단위 테스트는 미루지 않고 즉시 작성해야 한다.

3. TDD의 개념 및 절차

1. TDD의 개념

• Test-Driven Development = 테스트 주도 개발
• 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

  2. TDD 절차

  

1. RED 단계 : 실패하는 테스트 코드를 먼저 작성

2. GREEN 단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성

3. REFACTOR 단계 : 중복 코드 제거, 일반화 등의 리팩토링을 수행

4. 기존 방식과의 차이점

1. 기존 방식

• 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 있다.

• 코드들의 재사용이 어렵고 관리가 어려워져 유지보수를 어렵게 만든다.

  2. TDD 개발 방식

  

• 테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들을 테스트 케이스에 추가하고 설계를 개선한다.

• 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성

• 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해짐

5. TDD의 장점과 단점

1. 장점

1. 보다 튼튼한 객체 지향적인 코드 생산
2. 재설계 시간의 단축
3. 디버깅 시간의 단축
4. 테스트 문서의 대체 가능
5. 추가 구현의 용이함

2. 단점

1. 생산성이 저하될 수도 있음
2. TDD를 사용하지 않았을 때와 대비하여 초기 비용 발생
3. 팀이 테스트코드에 익숙하지 않은 경우 테스트코드에 집중할 수 없다.

이 글은 아래의 사이트 내용을 참고하였습니다. $\to$ https://wooaoe.tistory.com/33 $\to$ https://mangkyu.tistory.com/182 $\to$ https://mangkyu.tistory.com/143 $\to$ https://media.fastcampus.co.kr/knowledge/dev/tdd/ $\to$ https://velog.io/@sdb016/%EC%A2%8B%EC%9D%80-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-FIRST%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC $\to$ https://yuricoding.tistory.com/91

• 1. JUnit5 개념

• 2. JUnit5 어노테이션 종류
• 3. JUnit5 테스트 라이프 사이클
• 4. Assert 메서드
• 5. 보조 어노테이션
• 6. JUnit5 Assumption

1. JUnit5 개념

• JUnit5란 자바 개발자가 가장 많이 사용하는 테스팅 기반 프레임워크이다.

• Java8 부터 사용가능

• JUnit Platform, JUnit Jupiter, JUnit Vintage가 결합한 형태

  1. JUnit Platfor : 테스트를 실행해주는 런쳐와 TestEngine API를 제공
  2. Jupiter : TestEngine API 구현체로 JUnit5에서 제공
  3. Vintage : TestEngine API 구현체로 JUnit3, 4에서 제공

2. JUnit5 어노테이션 종류

3. JUnit5 테스트 라이프 사이클

하나의 테스트 클래스에서 아래와 같이 어노테이션을 설정하여 테스트 라이프 사이클을 만들 수 있다.

[Example1]

[Example2]

4. Assert 메서드

1. 기본

• assertEquals()

  2. 그룹

• 여러 검증을 하나로 묶어서 테스트하는 것
• assertAll()

  3. 예외처리

• 실행한 코드에서 특정 인셉션이 발생하는지 확인할 때 사용
• assertThrows()

  4. 시간초과

• 특정 시간 안에 실행이 끝나는지 확인하고 싶을 때 사용
• assertTimeout(), assertTimeoutPreemptively()

5. 보조 어노테이션

1. @DisplayName

• 테스트 클래스나 메서드의 표시 이름을 지정

2. @Disabled

• 테스트 실행 대상에서 제외

6. JUnit5 Assumption

• 특정 환경에 있을 때만 테스트를 진행하도록 할 때 사용

이 글은 아래의 사이트 내용을 참고하였습니다. $\to$ https://steady-coding.tistory.com/349 $\to$ https://insight-bgh.tistory.com/507 $\to$ https://velog.io/@ehddek/JUnit-%EC%9D%B4%EB%9E%80 $\to$ https://javacan.tistory.com/entry/JUnit-5-Intro $\to$ https://gaemi606.tistory.com/entry/JUnit5-Test-LifeCycle $\to$ https://beststar-1.tistory.com/28

• AWS 과금을 방지하는 방법들

1. 사용하지 않는 계정 및 리소스 삭제

2. MFA 설정하기

3. Git에 Access Key와 Secret key가 올라가지 않도록 항상 주의

4. 비용에 대한 알람 설정

결제 대시보드 - Budgets 에서 설정이 가능하다. free티어 사용량에 대한 알람, 지정된 예산에 대한 알람 등을 받을 수 있다.

5.요금 폭탄이 나오면 환불 요청을 해라.

AWS Support 센터에 티켓을 만들어 요금 해지 요청을 한다.

출처 : https://brunch.co.kr/@topasvga/1308

• 1. 경로 표현식

• 2. 다형성 쿼리
• 3. 엔티티 직접 사용
• 4. Named 쿼리
• 5. 벌크 연산

1. 경로 표현식

1. 경로 표현식 용어 정리

• 상태 필드(state field) : 단순히 값을 저장하기 위한 필드
• 연관 필드(association field) : 연관관계를 위한 필드

2. 경로 표현식 특징

• 상태 필드 : 경로 탐색의 끝. 탐색X
• 단일 값 연관 경로 : 묵시적 내부 조인(inner join) 발생. 탐색O
• 컬렉션 값 연관 경로 : 묵시적 내부 조인 발생. 탐색X(컬렉션으로 들어오는거라서 탐색을 할 수가 없음)

3. 명시적 조인 & 묵시적 조인

• 명시적 조인 : join 키워드 직접 사용
• 묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인 발생(내부 조인만 가능)

4. 실무 조언

• 가급적 묵시적 조인 대신에 명시적 조인 사용
• 조인은 SQL 튜닝에 중요 포인트
• 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

5. JPQL - 페치조인(fetch join)(실무에서 정말정말 중요함)

• SQL 조인 종류X
• JPQL에서 성능 최적화를 위해 제공하는 기능
• 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
• join fetch 명령어 사용
• 즉시로딩과 비슷(만약 그냥 따로 가져온다고 하면 지연로딩 때문에 n번 SQL이 나감 $\to$ N+1 문제 발생)

1. 일대다 상황

• 일에 해당하는 다의 수 만큼 컬렉션 개수가 결정됨(일대다에서 데이터가 뻥튀기 될 수 있다는 것을 유념)

2. 페치 조인과 일반 조인의 차이

• 일반 조인 : 단지 SELECT 절에서 지정한 엔티티만 조회할 뿐. 연관관계 고려X
• 페치 조인 : 연관된 엔티티도 함께 조회(즉시로딩). 객체 그래프를 SQL 한번에 조회하는 개념

3. 페치 조인의 특징과 한계

• 페치 조인 대상에는 별칭을 줄 수 없다.
• 둘 이상의 컬렉션은 페치 조인 할 수 없다.('일대다대다'가 되어서 곱하기가 됨 $\to$ 데이터가 예상하지 못하게 많이 늘어날 수 있음)
• 컬렉션을 페치 조인하면 페이징 API를 사용할 수 없다.(데이터가 뻥튀기 되고, 페이지 사이즈 설정에 따라 정보가 누락될 수 있기 때문) $\to$ 해결책1. 다대일로 방향을 뒤집어서 해결 $\to$ 해결책2. fetch join을 빼고,지연로딩으로 하는거 (근데 이거는 성능 안 나옴) $\to$ 해결책3. @BatchSize(size = 100)를 이용하기 = 지연로딩으로 끌어올때, 100개씩 넘기는거 (N+1을 해결하는 방법중 하나)(hibernate.default_batch_fetch_size의 value를 100으로 지정하고 진행할 수도 있음)

2. 다형성 쿼리

조회 대상을 특정 자식으로 한정

3. 엔티티 직접 사용

JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용

4. Named 쿼리

1. Named 쿼리 - 정적 쿼리

• 미리 정의해서 이름을 부여해두고 사용하는 SQL
• 어노테이션, XML에 정의
• 애플리케이션 로딩 시점에 초기화 후 재사용
• 애플리케이션 로딩 시점에 쿼리를 검증

2. Named 쿼리 - 어노테이션

3. Named 쿼리 - XML에 정의

4. SpringDateJPA 이용

public interface UserRepository extends JpaRepository<User, Long> {

    @Query("select u from User u where u.emailAddress = ?1")
    User findByEmailAddress(String emailAddresss);
}

• 여기에 있는 쿼리가 네임드 쿼리 역할 $\to$ 이름없는 네임드 쿼리
• JPA가 네임드쿼리로 등록해버림 $\to$ 파싱 시점에 에러 다 잡아줌
• 엔티티에 적는거는 너무 지저분해져서 springDataJpa에 섞어서 사용하기

5. 벌크 연산

• JPA는 벌크성보다는 실시간 단건에 집중되어있는 경향이 있음 $\to$ 그래서 벌크연산이라는 것을 제공
• 벌크연산 주의 사항 (1) 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리를 날림 (2) 그래서, 벌크 연산을 먼저 수행 후 영속성 컨텍스트 초기화하기!!!(em.clear())

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

• 1. 객체지향 쿼리 언어 소개

• 2. JPQL
• 3. 기본 문법과 기능
• 4. 페치 조인

1. 객체지향 쿼리 언어 소개

JPQl, JPA Criteria, QueryDSL, 네이티브 SQL, JDBC API 직접 사용, MyBati, SpringJdbcTemplate 함께 사용 $\to$ 복잡한 쿼리를 짤 수 있어야 한다는 것에서 시작

2. JPQL

1. JPQL

• 테이블이 아닌 객체를 대상으로 검색하는 객체 지향 쿼리(=객체지향SQL)(SQL은 데이터베이스 테이블을 대상으로 쿼리)
• JPQL을 짜면, 결국에는 SQL로 번역이 되어서 실행이 됨

2. Criteria

• 위의 JPQL은 결국 String 이라서 동적 쿼리를 날리기가 어려움(string끼기 띄워쓰기 등을 고려해서 붙일때 발생하는 여러가지 문제)
• 그래서 나온것이 Criteria
• 쿼리를 코드로 짜는 것
• 쉬운거 같으면서 어려움(sql같은거는 조금 더 직관적인데, 이거는 조금 혼란스러움)
• 동적 쿼리로 짜기가 좋다.
• Java코드라서 에러를 바로 확인 가능
• 결론 $\to$ 실무에서 안씀(못 알아보겠어서, 유지보수가 안됨 $\to$ 그냥 이런게 있구나 정도 $\to$ Criteria 대신에 Query DSL 사용 권장

3. QueryDSL

• 문자가 아닌 자바코드로 JPQL을 작성할 수 있음
• JPQL 빌더 역할
  • 컴파일 시점에 문법 오류를 찾을 수 있음
• 동적쿼리 작성 편리함
• 단순하고 쉬움
• 실무 사용 권장

4. 네이티브 SQL

• JPA가 제공하는 SQL을 직접 사용하는 기능
• JPQL로 해결할 수 없는 특정 데이터베이스에 의존적인 기능

5. 결론

JPQL과 QueryDSL을 잘 사용하자

3. 기본 문법과 기능

1. JPQL 문법

• 엔티티와 속성은 대소문자 구분함(Member, age)
• JPQL 키워드는 대소문자 구분 못함(SELECT, FROM, where)
• 엔티티 이름 사용, 테이블 이름이 아님(Member)
• 별칭은 필수(m)(as는 생략 가능)

2. TypeQuery, Query

• TypeQuery : 반환 타입이 명확할 때 사용
• Query : 반환 타입이 명확하지 않을 때 사용

3. 결과 조회 API

• query.getResultList() : 결과가 하나 이상일 때. 리스트 반환 $\to$ 결과가 없으면 빈 리스트 반환
• query.getSingleResult() : 결과가 정확히 하나. 단일 객체 반환 $\to$ 결과가 없거나, 둘 이상이면 exception 남

4. 파라미터 바인딩

(1) 이름 기준(이거 쓰기)

SELECT m FROM Member m where m.username=:username
query.setParameter("username", usernameParam);

(2) 위치 기준

SELECT m FROM Member m where m.username=?1
query.setParameter(1, usernameParam);

• 중간에 하나 끼워넣으면 순서가 밀리는 이유때문에, 이거 쓰지말기

5. 페이징 API

• JPA는 페이징을 다음 두 API로 추상화
• setFirstResult(int stratPosition) : 조회 시작 위치(0부터 시작)
• setMaxResults(int maxResult) : 조회할 데이터 수

4. 페치 조인

1. 내부조인

• 멤버는 있고 팀이 없는경우, 데이터가 아예 안 나옴
• SELECT m FROM Member m [INNER] JOIN m.team t

  2. 외부조인

• 멤버는 있고 팀이 없는경우, 팀 데이터는 다 널이고 멤버는 조회가 됨
• SELECT m FROM Member m LEFT [OUTER] JOIN m.team t

3. 서브쿼리

• JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능
• FROM 절의 서브 쿼리는 현재 JPQL에서 불가능 $\to$ 해결책1. 조인으로 풀어서 해결 $\to$ 해결책2. 쿼리를 두번 날리기

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

• 1. 기본값 타입

• 2. 임베디드 타입(복합 값 타입)
• 3. 값 타입과 불변 객체
• 4. 값 타입의 비교
• 5. 값 타입 컬렉션

1. 기본값 타입

1. JPA의 데이터 타입 분류

(1) 엔티티 타입

• @Entity로 정의하는 객체
• 데이터가 변해도 식별자로 지속해서 추적 가능

(2) 값 타입

• int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
• 식별자가 없고 값만 있으므로 변경시 추적 불가

2. 값 타입 분류

(1) 기본값 타입

• 자바 기본 타입(int, double), 래퍼 클래스(Integer, Long), String

(2) 임베디드 타입

• embedded type, 복합 값 타입

(3) 컬렉션 값 타입

• collection value type

3. 주의

• 자바의 기본 타입은 절대 공유하면 안됨

2. 임베디드 타입(복합 값 타입)

• 새로운 값 타입을 직접 정의할 수 있음
• 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
• 사용법 (1) @Embeddable : 값 타입을 정의하는 곳에 표시 (2) @Embedded : 값 타입을 사용하는 곳에 표시
• 장점 (1) 재사용 (2) 높은 응집도 (3) 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음
• 임베디드 타입과 테이블 맵핑 (1) 임베디드 타입은 엔티티의 값일 뿐이다. (2) 임베디드 타입을 사용하기 전과 후에 맵핑하는 테이블은 같다. (3) 객체와 테이블을 아주 세밀하게(find-grained) 맵핑하는 것이 가능 (4) 잘 설게한 ORM 애플리케이션은 맵핑한 테이블의 수보다 클래스의 수가 더 많음

3. 값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

1. 값 타입 공유 참조 & 값 타입 복사

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함(부작용 발생)
• 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
• 대신 값(인스턴스)를 복사해서 사용

  2. 한계 및 해결책

• 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.
• 객체의 공유 참조는 피할 수 없다.
• 객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단
• 값 타입은 불변 객체(immutable object)(생성 시점 이후 절대 값을 변경할 수 없는 객체)로 설계해야 함
• 생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨 $\to$ Setter가 없어서 값을 바꿀 수 없을때 바꾸는 법 = 변경을 원하는 값들로 객체를 다시 만든 후, 그 객체로 다시 세팅

불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다.

4. 값 타입의 비교

1. 동일성(identity) 비교

• 인스턴스의 참조 값을 비교, ==사용

  2. 동등성(equivalence) 비교

• 인스턴스의 값을 비교, equals() 사용
• 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야함
• equals를 오버라이드 해줘야 함(지원해주고 있는 형태를 참조해서 쓰기)(해쉬코드도 구현해줘야 함)(사실 현업에서 그렇게 비교할 일이 많지는 않다고 하심...)

5. 값 타입 컬렉션

Set과 List를 테이블의 DB에 저장할 수 없으므로, 별도로 뽑아야 함

1. 사용

• 값 타입을 하나 이상 저장할 때 사용
• @ElementCollection, @CollectionTable 사용

2. 수정 방법

• 값 타입은 변경하는게 아니라 새로운 걸로 완전히 교체해야함(앞의 내용 참고)
• 컬렉션의 경우, remove로 원래꺼 지우고, 새로 add를 하여 넣기

3. 제약 사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없다
• 값은 변경하면 추적이 어렵다
• 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. $\to$ 값 타입을 사요하면 안된다는 말...
• 값 타입 컬렉션을 맵핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 함. $\to$ null입력X, 중복 저장X

4. 진짜 사용법

• 진짜 간단할때만 사용. (치킨, 피자 같은거를 고를때)
• 주소, 이력과 같은 정보는 엔티티로 관리하기

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

• 프록시

• 즉시 로딩과 지연 로딩
• 지연 로딩 활용
• 영속성 전이 : CASCADE
• 고아 객체
• 영속성 전이 + 고아 객체, 생명주기

1. 프록시

1. em.getReference()

• 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회
• DB에 쿼리가 안 나가는데, 객체가 조회되는 것
• 진짜를 넘겨주는게 아니라, 가짜(프록시)엔티티 객체를 줌
• 껍데기는 같지만, 안에는 비어있는 것
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출

2. 프록시 객체의 초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

3. 프록시의 특징

• 프록시 객체는 처음 사용할 때 한 번만 초기화
• 프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초 기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능
• 프록시 객체는 원본 엔티티를 상속받음, 따라서 타입 체크시 주의해야함 (== 비 교 실패, 대신 instance of 사용)
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해 도 실제 엔티티 반환
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제 발생(하이버네이트는 org.hibernate.LazyInitializationException 예외를 터트림)

근데, getReference를 잘 쓰지는 않음 $\to$ 이거를 알아야지 즉시로딩과 지연로딩을 잘 이해할 수 있어서 배우는 것!

2. 즉시 로딩과 지연 로딩

1.즉시 로딩

• Member를 조회할 때 Team도 함께 조회하는 것

  2. 지연 로딩

  
• Member를 조회할 때 Team을 같이 조회하지 않고, Team을 사용할 일이 있을 때 조회를 하는 것

3. 프록시와 즉시로딩 주의

• 가급적 지연 로딩만 사용(여러개의 엔티티가 엮여있으면, 다 조회가 되는 문제 때문)
• 즉시 로딩은 JPQL에서 N+1 문제(최초쿼리는 1개인데, 그에 대한 추가 쿼리가 N가 나간다고 해서 N+1 문제)를 일으킴 $\to$ em.find의 경우는 JPA가 최적화를 해서 한번에 되지만, JPQL 같은 경우는 그냥 SQL을 날리면서 즉시로딩이 필요한거를 다시 또 가져옴
• @ManyToOne, @OneToOne은 기본이 즉시 로딩임. $\to$ LAZY로 설정 필요!!!

3. 지연 로딩 활용

이론적인 내용. 실무에서는 다 지연로딩으로 사용하기

4. 영속성 전이 : CASCADE

• 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용 $\to$ 엔티티를 영속화할 때, 연관된 엔티티도 함께 영속화하는 편리함을 제공
• 지연로딩, 즉시로딩, 연관관계 세팅과 전혀 관계가 없는 것
• 사용시기 (1) 하나의 부모가 자식을 관리할 때 의미가 있음 (소유자가 하나일때, parent만 child를 소유할 때) (2) 다른 것들과 관계가 있을 때 쓰면 안됨 (Child가 Parent 뿐만 아니라 다른 것들과 관계가 있을때)

5. 고아 객체

1. 고아 객체 제거

• 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제

  2. 주의

• 참조하는 곳이 하나일 때 사용해야 함
• 특정 엔티티가 개인 소유할 때 사용

6. 영속성 전이 + 고아 객체, 생명주기

• CascadeType.ALL + orphanRemovel=true
• 두 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있음
• 도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

• 매 달 3억명이 사용하는 서비스 터뜨리기, 그리고 예방하기 (이수재)

• 좋은 질문은 좋은 대답을 만든다 with relay (정미량)
• 만들어는 봤나?! 해커톤! (강윤수)
• 고양이는 야옹야옹하고 웁니다 (정문성, 이상민)
• 고등학생 CTO가 스타트업에서 살아남는 법 (권동한)
• 오픈소스에 초보 개발자가 기여하는 방법 (김성일)

1. 매 달 3억명이 사용하는 서비스 터뜨리기, 그리고 예방하기 (이수재)

1. 서버가 죽었다. (첫 번째 에러 경험)

• 문제점 및 해결 방안 (1) No Alert $\to$ Alert 생성 (2) No Linter $\to$ Linter 생성 (3) No Test $\to$ 시간이 없어도 테스트 하자... (4) Power of Feature Flags $\to$ 항상 동적으로 동작하게 하여 복구를 빠르게 하자. (5) Always Automate $\to$ 항상 자동화가 되게끔하라!

2. 서버가 죽지 않았는데, 검색이 안된다...(두 번째 에러 경험)

• 문제점 및 해결 방안 (1) (Not Enough) Alert (2) Dependency $\to$ 제대로 작동할것이라는 가정하에 프로그램을 동작시키면 안됨! (3) 외부 서비스는 항상 실패를 가정하자 (4) 중요한 것은 우리 서버만이 아닌 서비스다. $\to$ 코드의 존재 의의는 최종 사용자를 위한 것

3. 위의 두 가지 에러를 통해 강연자님께서 느낀점

(1) 빠른 성능, 좋은 기능도 좋지만 안정감 있고 신뢰감 있는 서비스가 먼저다.(BC2 경험을 통한 것) (2) 안전 장치 덕분에 릴리즈에 대한 부담이 줄어서 개발 속도가 오히려 빨라질 수도 있다.

2. 좋은 질문은 좋은 대답을 만든다 with relay (정미량)

• 행복한 질문 생활을 하기 위한 방법 (1) 문제 상황에 대해 깔끔하게 분석 후 정리하자. (2) 공식 Docs를 읽고, 공식적인 내요을 참조로 제시하자 (3) 충분한 고민 후에도 해결이 되지 않으면 질문하자. (4) 필요한 정보를 충분하고 간결하게 전달하자. (5) 질문 받는 사람은 맥락을 모른다. (6) 질문의 대상은 가까운 개발자분들, 사내 개발자분들 외에도 Stackoverflow, 공식 커뮤니티등이 될 수 있다. (7) 질문을 두려워하지 말자. (8) 질문 후 결과는 꼭 잘 정리해서 다시 공유를 하자.

• 질문 내용 정리(간단 버전) $\to$ 상황 $\to$ 맥락 $\to$ 무슨 시도를 했는지!! $\to$ 어떤것에 대한 답이 필요한지

3. 만들어는 봤나?! 해커톤! (강윤수)

해커톤을 기획하면서 겪은 어려운점 및 경험을 말씀해주셨습니다.

4. 고양이는 야옹야옹하고 웁니다 (정문성, 이상민)

• 고양이의 분리불안을 해소시키는 것을 목표로 토이프로젝트 시작하셨다고 함.

• 라즈베리파이, 소리 기술에 대한 머신러닝, Flutter 등을 이용하여 서비스 구축

• 느낀점 $\to$ 임베디드 관련해서 프로젝트를 할 때 너무 힘들었던 경험이 있었는데, 다시 이렇게 재밌는 서비스를 보니 또 다시 해보고 싶다는 생각이 든다. $\to$ Flutter를 빠르게 배우고 사용하셨다는 점에서, 새로운 기술을 배우고 빨리 적용시켜보고 싶은 욕심이 생긴다.

5. 고등학생 CTO가 스타트업에서 살아남는 법 (권동한)

vcl, 리팩토링 경험, FastAPI 등 다양한 경험에 대해서 얘기를 해주셨다. 아직까지 안 써본 기술들이라서 정확히 이해를 하지는 못했지만, 어린 나이에 빠른 시간 안에 성장한 모습을 보면서 많은 동기부여가 되었다!!!

6. 오픈소스에 초보 개발자가 기여하는 방법 (김성일)

1. 라이센스 규정에 대한 설명(MIT, APACHE, GPL)

2. 오픈 소스 기여가 좋은 이유

• 문제 해결 능력 상승 $\to$ 명확한 답이 없는 문제라서
• 커뮤니케이션 능력 상승 $\to$ 처음부터 끝까지 소통을 기반으로 함 + 영어로 소통하는 경우가 많음(기술적인 언어, 공적인 언어)

3. 기여를 시작하기 위한 대상을 찾는 법

• 관심이 있거나 사용하고 있는 오픈소스에 기여하자.(사용하는 프로그램 혹은 라이브러리에서 찾기)
• 스스로 불련한 점을 겪고 있는 것에서 찾아보기
• 작은 프로젝트부터 시작하기(큰 프로젝느는 구조 파악부터 너무 오래 걸림...)

4. 오픈 소스 기여과정 및 설명

(1) Issue(문제를 작성하는 과정)

• mainainer가 이해하기 쉽게, 최대한 자세하게 작성하기
• issue template가 있으면 형식에 맞춰 작성하기

(2) 코드 혹은 문서 수정 및 추가

(3) PR 작성 : 무엇을 어떻게 수정하였는지 최대한 자세하게 작성하자

(4) CI(지속적인 통합) : Github Actions와 같은 CI툴에 의해 코드 스타일 체크 및 테스트등을 수행

(5) Review : 단순히 검사를 받는 것이 아닌, 서로간의 소통을 통해 더 좋은 방법을 논의 하는 것

(6) Merge

5. 코드 작성만이 기여가 아니다.

• 오타 고치기
• 번역하기 (다수의 국가에서 사용되는 프로젝트는 번역이 필요함)
• 버그 제보하기

6. 오픈소스 기여시 주의할 점

(1) 올바르게 기여하기 : 가이드라인 준수(CONTRIBUTING.md) : 코딩 스타일 준수 (2) 기다림은 필수 : maintainer의 직업은 maintainer가 아니다! (3) 좌절하지 않기 : 항상 pr이 merge 될 수 없음 (그래도 시도 자체도 의미 있는 행위)

7. Tips

(1) Good First Issue(초보자가 고치기 쉬운 이슈) $\to$ 이걸 모아놓은 사이트도 있음 // Up For Grabs도 참고하기 (2) 오픈소스 컨트리뷰톤 이용하기 (3) 기여를 위한 기여하지 않기 : 이력서 한 줄을 위해, 억지로 기여하지 말자 : 억지로하면 흥미도 금방 잃고, 재미도 없다. : 자신이 관심있고 사용하는걸 하자!!

강연자님의 참고 레퍼런스

이 글은 '소주콘(소문난 주니어 콘퍼런스) Shot 1 : 진로 빨강 뚜껑'에 참석하고 정리한 내용입니다.

• 1. 상속관계 맵핑

• 2. @MappedSuperclass

1. 상속관계 맵핑

• 관계형 데이터베이스는 상속관계X
• 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
• 상속관계 맵핑 = 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법(객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 맵핑)
• 전략 3개 (1) 각각의 테이블로 변환 $\to$ 조인 전략 (2) 통합 테이블로 변환 $\to$ 단인 테이블 전략 (3) 서브타입 테이블로 변환 $\to$ 구현 클래스마다 테이블 전략 $\to$ 논리 모델을 위와 같은 3가지의 구체적인 물리모델로 구현할 수 있는데, 객체 입장에서는 다 똑같음.
• 주요 어노테이션 (1) @Inheritance(strategy=IngetitanceType.XXX) $\to$ JOINED : 조인전략 $\to$ SINGLE_TABLE : 단일 테이블 전략 $\to$ TABLE_PER_CLASS : 구현 클래스마다 테이블 전략 (2) DiscriminatorColumn(name="DTYPE") (3) DiscriminatorValue("XXX")

1. 조인 전략

(1) 장점

• 테이블 정규화
• 외래 키 참조 무결성 제약조건 활용가능
• 저장공간 효율화 (2) 단점
• 조회시 조인을 많이 사용, 성능 저하
• 조회 쿼리가 복잡함
• 데이터 저장시 INSERT SQL 2번 호출 (3) DTYPE
• 구분하는 컬럼
• 쿼리를 날렸을 때, 자식의 누구때문에 들어온건지 알 수 있게 해줌 $\to$ 운영이나 DB의 작업에서 필요한것 (@DiscriminatorColumn을 쓰면 설정 됨)
• 자식 클래스에 @DiscriminatorValue("XXX")를 설정하므로써 Entity명이 아닌 다른 이름으로 바꿔서 DTYPE에 표현할 수 있음(@DiscriminatorValue("M")으로 하면, MEMBER로 표시되는게 M으로 표시 됨)

2. 단일 테이블 전략

1. 장점

• 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
• 조회 쿼리가 단순함

2. 단점

• 자식 엔티티가 맵핑한 컬럼은 모두 null 허용
• 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있음. 상황에 따라서 조회 성능이 오히려 느려질 수 있음.

3. 추가사항

• 단일테이블에서 @DiscriminatorColumn을 안써도 DTYPE 생성해줌 $\to$ 조인전략에서는 테이블이 분리되어있으니깐 어떻게든 누구의 데이터인지 알 수 있는데, 단일 테이블에서는 알 수 있는 방법이 없음. 그래서 DTYPE이 필수로 생성됨

3. 구현 클래스마다 테이블전략

1. 장점

• 서브 타입을 명확하게 구분해서 처리할 때 효과적
• not null 제약조건 사용 가능

2. 단점

• 여러 자식 테이블을 함께 조회할 때 성능이 느림(UNION SQL 필요)
• 자식 테이블을 통합해서 쿼리하기 어려움

3. 추가 개념

• @DiscriminatorColumn이 의미가 없음(넣어도 사용 안됨)(테이블 자체가 다르기때문에)
• 특정 한 곳에서 가져올 때는 괜찮은데, 부모 클래스에서 가져올때는 모든 것을 다 확인하고 가져옴

4. 전략 3가지 정리

1. 조인 전략

• 이게 정석
• 외래 키 참조 무결성 제약조건 활용가능(다른 테이블에서 부모클래스만 보면 된다는거)

2. 단일 테이블 전략

• 단순하고, 확장할 가능성도 별로 없을꺼 같을때 이거 선택
• null 허용한다는게 치명적인 단점

3. 구현 클래스마다 테이블 전략

• 묶이는게 없음
• 이거 쓰면 안됨.

2. @MappedSuperclass

• DB는 다른데 객체 입장에서 속성만 상속해서 사용하고 싶을때 사용
• 하나의 클래스를 @MappedSuperclass를 이용해서 만들고, extends를 이용해서 다른 클래스들이 상속 받기
• 조금 더 정확하게 말하면 상속관계 맵핑이 아님. 그냥 속성만 내려주는 것
• 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
• 참고 : @Entity 클래스는 엔티티나 @MappedSuperClass로 지정한 클래스만 상속 가능

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

• 1. 연관관계 맵핑시 고려사항 3가지

• 2. 다대일[N:1]
• 3. 일대다[1:N]
• 4. 일대일[1:1]
• 5. 다대다[N:M]

1. 연관관계 맵핑시 고려사항 3가지

1. 다중성

@ManyToOne, @OneToMany, @OneToOne, @ManyToMany

2. 단방향, 양방향

1. 테이블

• 외래 키 하나로 양쪽 조인 가능
• 사실 방향이라는 개념이 없음

2. 객체

• 참조용 필드가 있는 쪽으로만 참조 가능
• 한쪽만 참조하면 단방향
• 양쪽이 서로 참조하면 양방향

3. 연관관계의 주인

• 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음
• 객체 양방향 관계는 참조가 2군데 있음. 둘 중에 테이블의 외래 키를 관리할 곳을 지정해야 함.
• 연관관계의 주인 = 외래 키를 관리하는 참조
• 주인의 반대편 = 외래 키에 영향을 주지 않음. 단순 조회만 가능

2. 다대일[N:1]

• 가장 많이 사용하는 연관관계

3. 일대다[1:N]

• 권장하지 않음(실무에서 거의 안 쓰신다고 함...)
• 일대다 단방향 맵핑보다는 다대일 양방향 맵핑을 사용하자

4. 일대일[1:1]

• 주 테이블이나 대상 테이블 중에 외래 키 선택 가능
• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가
• 외래 키 관련 예시(외래키를 MEMBER에 두기 vs LOCKER에 두기)
  1. DBA 입장 (1) 시간이 지나서 비지니스 룰이 '하나의 회원이 여러 개의 라커를 가지게 한다.'로 바뀌면, LOCKER쪽에 외래키가 있는게 더 바꾸기 쉬움 (만약에 MEMBER에 외래키가 있으면, 변경 포인트가 많음) (2) '하나의 라커를 여러명이 공유하도록 한다.' 면 반대가 맞음
  2. 개발자 입장 (1) 멤버에 라커가 있는게 여러가지로 유리 $\to$ 멤버를 조회할 때, 라커에 대한 값이 있는지 없는지 쉽게 나옴

5. 다대다[N:M]

• 실무에서 쓰면 안됨 추가데이터가 들어오면 쓸 수가 없음(중간테이블에 맵핑 정보만 들어가고, 추가 정보를 더 넣는게 불가능 하다는 것) 쿼리가 직관적이지 않게 날라감(중간테이블 때문에 생각한것과 다르게 쿼리가 나감)
• 한계 극복 $\to$ @OneToMany, @ManyToOne으로 변경

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.

1. AWS 서비스에서 처리해야 하는 것들
2. 로컬 환경에서 처리해야 하는 것들

1. AWS 서비스에서 처리해야 하는 것들

1. S3 bucket 생성
2. 퍼블릭 엑세스 설정
3. 퍼블릭 정책 활성화

• 버킷 정책 생성 참고

4. 엑세스 키 생성

• S3에 접근하려면 별도의 인증 과정이 필요한데, 이때 사용되는 것이 엑세스 키
• 엑세스 키는 AWSAccessKeyId와 AWSSecretKey로 구성
• 이거를 application.yml과 같은 파일에 입력해줘야함.(GitHub 이용할때, 이런 정보들 안 올리도록 조심!!! ./gitignore 이용!!!)

2. 로컬 환경에서 처리해야 하는 것들

1. gradle 설정

상황마다 달라서, 구글링해보기

2. S3Uploader.java 생성

@Slf4j
@RequiredArgsConstructor
@Component
public class S3Uploader {

    private final AmazonS3Client amazonS3Client;

    @Value("${cloud.aws.s3.bucket}")
    private String bucket;

    public String upload(MultipartFile multipartFile, String dirName) throws IOException {
        File uploadFile = convert(multipartFile)
                .orElseThrow(() -> new IllegalArgumentException("MultipartFile -> File로 전환이 실패했습니다."));

        return upload(uploadFile, dirName); // 밑으로 이동
    }

    private String upload(File uploadFile, String dirName) {
        String fileName = dirName + "/" + uploadFile.getName();
        String uploadImageUrl = putS3(uploadFile, fileName); // 여기에서 S3에 올리는듯 // 밑에 함수
        removeNewFile(uploadFile); // 맨 밑에 함수
        return uploadImageUrl;
    }

    private String putS3(File uploadFile, String fileName) { // 여기서 실제로 s3에 올라감
        amazonS3Client.putObject(new PutObjectRequest(bucket, fileName, uploadFile).withCannedAcl(CannedAccessControlList.PublicRead));
        return amazonS3Client.getUrl(bucket, fileName).toString();
    }

    private void removeNewFile(File targetFile) { // 로컬에 저장한 정보를 이용해서 올렸다가, 로컬에 저장된거를 지우는거 같은데?
        if (targetFile.delete()) {
            log.info("파일이 삭제되었습니다."); //이게 제대로 실행 되는거
        } else {
            log.info("파일이 삭제되지 못했습니다.");
        }
    }

    private Optional<File> convert(MultipartFile file) throws IOException {
        String fileName = file.getOriginalFilename();
        File convertFile = new File(file.getOriginalFilename());
        //System.out.println(convertFile.createNewFile()); // 이미 있으면 false, 없으면 true
        if(convertFile.createNewFile()) { // 파일이 이전에 존재하지 않으면 true를 띄우고 들어감.
            try (FileOutputStream fos = new FileOutputStream(convertFile)) {
                fos.write(file.getBytes());
            }
            return Optional.of(convertFile);
        }
        return Optional.empty();
    }


}

• S3Uploader.java $\to$ S3에 정적 파일을 올리는 기능을 함
• 동작 방식 (1) MultipartFile을 전달 받음 (2) convert를 통하여 MultipartFile을 File로 전환 (3) 전환된 File을 S3에 'public 읽기' 권한으로 put (4) 로컬에 생성된 File 삭제(MultipartFile을 File로 전환하는 과정에서 로컬에 파일이 생성되었음) (5) 업로드된 파일의 S3 URL 주소를 반환
• 위의 코드에서 'dirName'은 S3에 생성된 디렉토리

3. Controller

@PostMapping("/upload")
    @ResponseBody
    public String upload(@RequestParam("data") MultipartFile multipartFile) throws IOException {
        return s3Uploader.upload(multipartFile, "static");
    }

받아온 multipartFile과 S3에 생성된 디렉토리의 이름(여기에서는 "static")을 입력

이 글은 향로님의 'SpringBoot & AWS S3 연동하기'를 통해 기능을 구현해보고 정리한 내용입니다.

1. Specification을 구현하는 방법

1. Specification

1. Repository에서 JpaSpecificationExecutor를 상속받기

• JpaSpecificationExecutor에는 기존의 JpaRepository에 있는 메서드와 비슷하지만 인자로 Specification이 있다는 점이 다름

2. criteriaBuilder를 통해, 지정된 객체에 아래와 같은 방식을 통해 다양한 쿼리를 날림.

criteriaBuilder.equal(root.get("name"), name);

criteriaBuilder.like(root.get("content"), "%" + content + "%");

criteriaBuilder.equal(root.get("origin"), origin);

criteriaBuilder.between(root.get("date"), start, end);

criteriaBuilder.lessThanOrEqualTo(root.get("date"), end);

아래는 자세한 코드

public class ItemSpecification {
    public static Specification<Item> equalName(String name){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.equal(root.get("name"), name);
            }
        };
    }

    public static Specification<Item> likeContent(String content){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.like(root.get("content"), "%" + content + "%");
            }
        };
    }

    public static Specification<Item> equalOrigin(String origin){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.equal(root.get("origin"), origin);
            }
        };
    }

    public static Specification<Item> betweenDate(LocalDate start, LocalDate end){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.between(root.get("date"), start, end);
            }
        };
    }

    public static Specification<Item> greaterThanOrEqualDate(LocalDate start){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.greaterThanOrEqualTo(root.get("date"), start);
            }
        };
    }

    public static Specification<Item> lessThanOrEqualDate(LocalDate end){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.lessThanOrEqualTo(root.get("date"), end);
            }
        };
    }

    public static Specification<Item> betweenPrice(Long min, Long max){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.between(root.get("price"), min, max);
            }
        };
    }

    public static Specification<Item> greaterThanOrEqualPrice(Long min){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.greaterThanOrEqualTo(root.get("price"), min);
            }
        };
    }

    public static Specification<Item> lessThanOrEqualPrice(Long max){
        return new Specification<Item>() {
            @Override
            public Predicate toPredicate(Root<Item> root, CriteriaQuery<?> query, CriteriaBuilder criteriaBuilder) {
                return criteriaBuilder.lessThanOrEqualTo(root.get("price"), max);
            }
        };
    }

}

3. Controller 에서의 구현

Specification<Item> spec = (root, query, criteriaBuilder) -> null;

        if(name != null){
            spec = spec.and(ItemSpecification.equalName(name));
        }
        if(content != null){
            spec = spec.and(ItemSpecification.likeContent(content));
        }
        if(origin != null){
            spec = spec.and(ItemSpecification.equalOrigin(origin));
        }
        if(start != null && end != null){
            spec = spec.and(ItemSpecification.betweenDate(start, end));
        }
        if(start != null && end != null){
            spec = spec.and(ItemSpecification.greaterThanOrEqualDate(start));
        }
        if(start == null && end != null){
            spec = spec.and(ItemSpecification.lessThanOrEqualDate(end));
        }
        if(min != null && max != null){
            spec = spec.and(ItemSpecification.betweenPrice(min, max));
        }
        if(min != null && max == null){
            spec = spec.and(ItemSpecification.greaterThanOrEqualPrice(min));
        }
        if(min == null && max != null){
            spec = spec.and(ItemSpecification.lessThanOrEqualPrice(max));
        }


        model.addAttribute("specResults", itemRepository.findAll(spec));

1. Controller에서 Specification<Item> spec = (root, query, criteriaBuilder) -> null; 로 설정하여 일단 spec을 정의
2. 그리고 spec = spec.and(ItemSpecification.equalName(name)) 등을 통해 계속해서 찾고자 하는 조건 추가
3. 마지막에 itemRepository.findAll(spec));을 통해 한번에 가져옴

• 1. Git과 GitHub의 차이

• 2. Git의 특징(분산 버전 관리 시스템)
• 3. 충돌 관리
• 4. Repository Workflow
• 5. Convention(협약)
• 6. Management
• 7. Collaboration(협업)
• 8. Pull Request

1. Git과 GitHub의 차이

GitHub는 Git을 활용한 code hosting platform이다.

2. Git의 특징

1. Git

• 분산(Distributed) 버전 관리 시스템 $\to$ 분산이란? = 각각의 컴퓨터에 저장소(Repository)가 분리되어 있다.(commit을 하면 자신의 repository에 쌓이고, push를 하면 remote repository에 올라가는 거!!)

2. 흐름

1. Clone 또는 Init Local Repsitory 생성
2. commit Local repository에 작업이 쌓이는 것
3. push(local과 remote sync를 맞추는 것) Remote repository에 작업이 올라가는 것
4. pull(local과 remote sync를 맞추는 것) Remote repository에서 Local repository로 작업을 가져오는것

3. 충돌 관리

1. 충돌이 발생하는 이유

협업자 간 Git History 불일치

2. 충돌 분석

• 충돌 위치(파일, 라인)
• 충돌 유형(단순 코드 스타일 차이, 로직 변경 또는 리팩터링, 동시 추가)
• 충돌 원인(이력이 틀어진 시점)

3. 하면 안되는 것

• 발생한 충돌을 의논 없이 수정하기(단순 코드 스타일 제외 = 코드 스타일을 정의해놨다는 전제하에는 지워도 됨)
• git push --force(branch랑 commit history가 틀어짐)

4. Repository Workflow

1. Centralized 와 Forking의 차이

(1) Centralized

• "Origin - Local"로 구성
• Remote repository(그룹저장소)가 origin이 되고, Local repository(개인 저장소)가 Local이 됨

(2) Fork

• "Upstream - Origin - Local"로 구성
• Remote repository(그룹저장소)가 Upastream이 되고, Local repository(개인 저장소)가 Origin이 됨
• push를 하면 개인저장소(origin)에 들어감 $\to$ 그룹저장소에는 반영이 안됨
• PR로 개인 저장소와 그룹 저장소 sync 맞추기

5. Convention(협약)

(1) Coding Style Naming, Indentation, Quote (2) Structure File / Directory, Architecture (3) Commit Conventional Commits, Angular Commit Message (4) Branching Git Flow, GitHub Flow, GitLab Flow (5) Automation CI / CD

6. Management

1. Issue

• 문제
• 할 일(TODO)
• 관심사

  2. Issue를 잘 사용하는 법

• '레이블'을 달아서 시각적으로 만들기
• 'template' 사용하기(.github를 만들고, template 생성하면 됨)
• 'Project(진행상황별로 기록)와 'Milestone(기한을 맞추어서 작업해야 하는 것)'사용

3. GitHub Issue의 Pros and Cons(Jira와 같은 다른 도구와 비교)

(1) 장점

• 접근성이 높다.
• 도구의 파편화를 막을 수 있다.
• Jira보다 빠르다.
• 누구나 볼 수 있다.(Jira는 초대된 팀 멤버만 볼 수 있음)

(2) 단점

• Project와 Milestone 등이 아직 불편함.

7. Collaboration(협업)

1. 존중합시다.

2. 친절합시다.

3. 겸손합시다.

8. Pull Request

• 코드를 통합하는 방법 중 하나
• Git의 기능이 아닌, GitHub의 기능
• 코드 리뷰 수행 가능

이 글은 DND에서 제공된 'GitHub로 협업하기' 세미나를 듣고 정리한 내용입니다.

• 1. 클라우드를 공부하려고 AWS 가입부터 한다.

• 2. AWS 루트 계정에 아이디와 암호만으로 로그인한다.
• 3. 아무 블로그에 있는 실습에 따라 Github에 코드를 올린다
• 4. 복잡하고 돈이 드는 아키텍처를 먼저 공부한다.
• 5. 처음부터 복잡한 클라우드 아키텍처를 구현한다.
• 6. 매월 초가 되어서야 AWS 요금이 나온걸 알았다.
• 7. 혼자 AWS 문제를 해결을 해보려고 애쓴다.
• 8. AWS 문제 해결을 위해 영어로 힘들게 이야기 하고 있다.
• 9. 서비스 개발 및 배포에만 클라우드를 쓰고 있다.
• 10. 클라우드 공부 방법과 경력 개발에 대해 혼자 고민하고 있다.

1. 클라우드를 공부하려고 AWS 가입부터 한다.

$\to$ AWS 무료 교육 및 실습을 활용하세요.

• AWSOME DAY 참여하기
• AWS Educate
• Amazon SageMaker Studio Lab(이걸로 머신러닝 되는거 같음)

2. AWS 루트 계정에 아이디와 암호만으로 로그인한다.

$\to$ 멀티팩터인증(MFA)를 설정하세요

• MFA 추가하고, 로그인 할때마다 MFA를 추가적으로 인증하기

3. 아무 블로그에 있는 실습에 따라 Github에 코드를 올린다

$\to$ IAM USER로 사용 권한을 제한하세요.

• '엑세스 키ID'와 'Seceret Key'는 누구와도 공유하면 안됨 (특히 깃헙 같은 곳에 올리면 안됨)(해킹에 의해 과다 요금이 나오기도 함)
• 엑세스키가 꼭 필요하다면 루트 사용자 대신 IAM 사용자에 연결된 키를 사용하기

4. 복잡하고 돈이 드는 아키텍처를 먼저 공부한다.

$\to$ AWS 실습 가이드를 활용하자

• AWS 시작하기 페이지에 가면 단계별 자습서가 있음

5. 처음부터 복잡한 클라우드 아키텍처를 구현한다.

$\to$ Amazon LightSail을 이용하세요.

• '천만 사용자를 위한 클라우드 아키텍처' 강의가 매년 업데이트 되고 있으니깐 참고하기.
• '가상 서버, 애플리케이션 배포, 데이터베이스, 네트워킹, 스토리지 등 다양한 기능'이 있는 것이 Amazon LightSail

6. 매월 초가 되어서야 AWS 요금이 나온걸 알았다.

$\to$ AWS Budget 알람을 설정하세요.

• 과금 알람 설정하기
• 월별 예산을 설정하고 예산이 소비되는 %에 따라서 알람이 오게 할 수 있음.

7. 혼자 AWS 문제를 해결을 해보려고 애쓴다.

$\to$ AWS Trusted Advisor를 활용하세요.

• 축적된 모범 사례를 통해 어드바이저를 주는 것.
• 한달에 30달러 정도를 부과하면 24시간 AWS support enginer의 도움도 받을 수 있음

8. AWS 문제 해결을 위해 영어로 힘들게 이야기 하고 있다.

$\to$ AWS 한국어 기술 지원을 활용하세요.

• 티켓의 이름을 한국어로 지정하면 한국어 엔지니어에게 문제가 배치될 수 있음
• 또한, '한국 사람에게 배치해주세요.'라고 글을 남겨도 됨.

9. 서비스 개발 및 배포에만 클라우드를 쓰고 있다.

$\to$ 국내 사업 지원 프로그램을 활용하세요.

• AWS Korea의 사람들과 연결 고리(AWS 문의하기로 요청하면 됨)
• AWS Activate, AWS Smart Boost Up, AWS 파트너 프로그램,

10. 클라우드 공부 방법과 경력 개발에 대해 혼자 고민하고 있다.

$\to$ AWS 커뮤니티에 참여하세요.

• AWS 한국 사용자 모임(AWSKRUG) 이용하기
• 페이스북(awkrug.org), slack(slack.awkrug.org), meetup(meetup.com/awskrug), 카카오톡(AWS의 모든것), 유튜브(youtube.com/awskrug) 이용

*AWS 디지털 교육 * : AWS Skill Builder 이용하기

이 글은 'AWS Builders Online Series'의 'AWS 사용자의 10가지 실수 - 이것만은 피하세요!'에 참석하고 정리한 내용입니다.

• lower_bound와 upper_bound

• 시계방향과 반시계방향 회전
• 배열의 합(accumulate), 배열 중 가장 큰 요소(max_element), 배열 부분 회전
• 함수인자로 전달해서 변수 수정하기
• n진법 변환
• 내림차순 정렬 & 커스텀 정렬
• 2차원 배열을 회전하는 함수

1. lower_bound와 upper_bound

• 정렬된 배열에서 어떤 값이 나오는 지점이나 어떤 값이 나오기 전의 위치를 반환하려고 할 때 사용
• 그림 (1) lower_bound : 0번째 배열의 원소부터 찾아서 어떠한 값의 '이상이 되는 위치'를 반환 (2) upper_bound : 그 값이 시작되기 전의 위치를 반환(뒤에서부터라고 생각) $\to$ 1, 2, 2, 3, 4에서 upper_bound(2)를 하면 3을 return $\to$ 반환되는 값은 이터레이터이기 때문에 v.begin() 또는 a[0]을 빼주어서, int형으로 몇번째인지를 파악
• 찾고자 하는 수가 없는 경우 (1) "1, 2, 3, 5"에서 lower_bound(a.begin(), a.end(), 4) - a.begin()은 3을 반환(5를 가르키는 인덱스) (2) "2, 3, 4, 5, 7"에서 범위의 양 끝단을 벗어나는 경우

  cout << upper_bound(v.begin(), v.end(), 6) - v.begin() << endl; // 4(7을 가르킴)
  cout << lower_bound(v.begin(), v.end(), 6) - v.begin() << endl; // 4(7을 가르킴)
  cout << upper_bound(v.begin(), v.end(), 9) - v.begin() << endl; // 5
  cout << lower_bound(v.begin(), v.end(), 9) - v.begin() << endl; // 5
  cout << upper_bound(v.begin(), v.end(), 0) - v.begin() << endl; // 0
  cout << lower_bound(v.begin(), v.end(), 0) - v.begin() << endl; // 0

2. 시계방향과 반시계방향 회전

• rotata(first, middle, last)
• first와 last 사이에 있는 부분배열에서, middle이 가리키는 요소가 first로 가며 회전한다고 생각

  rotate(v.begin(), v.begin() + v.size() - 1, v.end()); // 시계 방향 
  rotate(v.begin(), v.begin() + 1, v.end()); // 반시계 방향 

3. 배열의 합(accumulate), 배열 중 가장 큰 요소(max_element), 배열 부분 회전

1. 배열의 합(accumulate) accumulate(v.begin(), v.end(), 0);
2. 배열 중 가장 큰 요소(max_element) max_element(v.begin(), v.end());
3. 배열 부분 회전

• 아래 코드는 반시계방향으로 회전이고, 응용을 하면 시계방향으로도 가능

  int temp = v[i];
  v[i] = v[i + 1];
  v[i + 1] = v[i + 2];
  v[i + 2] = v[i + 3];
  v[i + 3] = temp;

4. 함수인자로 전달해서 변수 수정하기

(1) void ch1(int %a) a = 2; $\to$ ch1(a)로 함수 호출 (2) void ch2(int *a) *a = 3; $\to$ ch1(&a)로 함수 호출

5. n진법 변환

#include <bits/stdc++.h>
using namespace std;
vector<int> v;

int main(){
    int n = 100;
    int b = 2; // 바꿀 진법

    while(n > 1){
        v.push_back(n % b);
        n /= b;
    }

    if(n==1) v.push_back(1);
    reverse(v.begin(), v.end());
    for(int a : v){
        if(a >= 10)
            cout << char(a + 55);
        else
            cout << a;
    }

    return 0;
}

6. 내림차순 정렬 & 커스텀 정렬

sort(v.begin(), v.end(), greater<int>());
sort(v.begin(), v.end(), greater<pair<int, int>>());

sort(v.begin(), v.end(), cmp);

7. 2차원 배열을 회전하는 함수

// 왼쪽으로 90도
void rotate90(vector<vector<int>> &key){
    int m = key.size();
    vector<vector<int>> temp(m, vector<int>(m, 0));
    for(int i = 0; i < m; i++){
        for(int j = 0; j < m; j++){
            temp[i][j] = key[j][m - i - 1];
        }
    }
    key = temp;
    return;
}
// 오른쪽으로 90도
void rotate90(vector<vector<int>> &key){
    int m = key.size();
    vector<vector<int>> temp(m, vector<int>(m, 0));
    for(int i = 0; i < m; i++){
        for(int j = 0; j < m; j++){
            temp[i][j] = key[m - j - 1][i];
        }
    }
    key = temp;
    return;
}

이 글은 큰돌님의 '10주완성 C++코딩테스트 | 알고리즘 IT취업'을 수강하고 정리한 내용입니다.

• 포인터

• 수학

1. 포인터

1. 포인터

• 주소연산자 & $\to$ &변수로 사용 $\to$ 주소값 반환

• 참조 연산자 * $\to$ *포인터의 이름, *주소로 사용 $\to$ 포인터에 저장된 주소에 저장되어 있는 값을 반환

• 포인터를 이용하여 값을 꺼내는 방법 두 가지 (1) (pointer_name)->(variable_name) (2) (*pointer_name).variable_name

2. 이터레이터와 포인터

• 이터레이터 (1) 컨테이너(배열 등)의 메모리 주소를 가리키는 데 사용되며 주소값을 바로 반환하지 않는 포인터의 일종(begin()과 end()를 많이 씀) (2) 주소값을 바로 반환하지 않기 때문에 주소값을 출력하려면 &*를 통해 출력해야 함

  cout << v.begin() << endl; // 에러
  cout << &*(v.begin()) << endl; // 주소값 출력

3. call by reference & call by value

• 어떠한 값을 함수로 넘겨서 변하게 만들고 싶을 때는 주소값을 넘겨야 함
• 그저 값만 넘기면 안됨!

4. 배열과 포인터

• 배열의 이름은 배열의 주소값의 첫 번째 시작 주소를 가르킨다.

2. 수학

1. 순열과 조합

1. 순열(permutation)

• 순서가 정해진 임의의 집합을 다른 순서로 섞는 연산

2. 조합(combination)

• 순서가 없음
• 몇 명을 뽑아서 갈 것인가를 쓸 때 사용

2. 정수론

1. 최대공약수(gcd)와 최소공배수(lcm)

   int gcd(int a, int b){
    if(a == 0)
        return b;
   
    return gcd(b % a, a);
   }
   

int lcm(int a, int b){ return (a*b) / gcd(a, b); }

```

2. 모듈러 연산 (1) a ≡ b mod n과 b ≡ c mod n 은 a ≡ c mod n 을 의미 (2) [(a mod n)+(b mod n)] mod n = (a+b) mod n (3) [(a mod n)-(b mod n)] mod n = (a-b) mod n (4) [(a mod n)(b mod n)] mod n = (ab) mod n

3. 에라토스테네스의 채

• 소수가 아닌 값들에 대한 불리언 배열을 만들어 소수만을 걸러낼 수 있는 방법

4. 등차수열의 합

• 등차수열의 합 = n(n+1) / 2

이 글은 큰돌님의 '10주완성 C++코딩테스트 | 알고리즘 IT취업'을 수강하고 정리한 내용입니다.

• 1. JpaRepository

• 2. 다중 필터링
• 3. 주의 사항

1. JpaRepository

• JpaRepository만 잘 사용해도 기본적인 필터링 기능을 구현할 수 있을 것이라고 생각한다.

  1. JpaRepository 정의 및 설명

  (1) Spring Data JPA에서 제공하는 인터페이스 (2) 인터페이스에 따로 @Repository등의 어노테이션을 추가할 필요가 없다.

2. 사용법

JpaRepository를 상속받을 때는 사용될 Entity 클래스와 ID값이 들어가게 된다. public interface ItemRepository extends JpaRepository<Item, Long>

3. 기본 기능(단순히 상속하는 것만으로도 아래 기능 제공)

(1) save() (2) findOne() (3) findAll() (4) count() (5) delete()

4. Query 메소드 추가

$\to$ 규칙에 맞는 메서드를 작성해야 한다. (1) findBy로 시작 => 쿼리를 요청하는 메서드 (2) countBy로 시작 => 쿼리 결과 레코드 수를 요청하는 메서드 (3) 실제 사용

    List<Item> findByDateBetween(LocalDate start, LocalDate end); // start 시간부터 end시간까지
    List<Item> findByPriceBetween(Long min, Long max); // min 가격부터 max 가격까지

2. 다중 필터링

• And와 Or을 사용하여 다중 필터링을 구현할 수 있다. List<Item> findByDateBetweenAndPriceBetween(LocalDate start, LocalDate end, Long min, Long max); List<Item> findByDateBetweenOrPriceBetween(LocalDate start, LocalDate end, Long min, Long max);

3. 주의 사항

• API를 통하여 start와 end 같은 시간을 가져올 때, @DateTimeFormat(iso = DateTimeFormat.ISO.DATE) 등의 방식을 추가해야지 시간으로 입력이 받아짐.