자주 출제되는 SQL 내장함수

날짜,시간 데이터

• 날짜 형식 변경

  # DATE_FORMAT(필드명, 형식)
  DATE_FORMAT(CREATED_DATE, "%Y-%m-%d")
  # 날짜가 아닌걸 날짜로 바꿈.
  TO_DATE(날짜, format)

• 날짜 차이 계산

  # 30일을 기준으로 장기대여/단기대여 분류해 RENT_TYPE에 저장
  CASE
    WHEN DATEDIFF(ENDTIME, STARTTIME)+1 > 30 THEN '장기대여'
    WHEN DATEDIFF(ENDTIME, STARTTIME)+1 = 30 THEN '일반대여'
    ELSE '단기대여'
  END RENT_TYPE
  

내가 지정한 단위 기준으로 차이 계산

TIMESTAMPDIFF(단위, 날짜1, 날짜2)

날짜 더하기/빼기

DATE_ADD(DATE, INTERVAL 1 HOUR) DATE_SUB(DATE, INTERVAL 3 HOUR)

- 날짜 범위 계산
```sql
-- 2022-10-16일에 차를 빌릴 수 있는지 여부
SELECT CAR_ID,
        MAX(CASE WHEN '2022-10-16' BETWEEN START_DATE AND END_DATE THEN "대여중" ELSE "대여 가능" END) AS AVAILABILTY
FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
GROUP BY CAR_ID
ORDER BY CAR_ID DESC

문자열 가공

• 특정 문자열 찾기 % : 0개 이상의 문자열 _ : 1개의 문자열 ^a : a로 시작하는 문자열 a$ : a로 끝나는 문자열 [abc] : a,b,c 중 하나의 문자 [^abc] a,b,c를 제외한 하나의 문자 [a-z] : a~z 중 하나의 문자 .* : 모든 문자열

# 데이터 찾기
WHERE LANGAUGE LIKE "%파이썬%"
WHERE LANGAUGE REGEXP 정규식
WHERE LANGAUGE IN ('가','나','다')

# 문자열 위치 찾기
LOCATE(str, 찾는 문자열)  # 문자열 내에서 찾는 문자열이 처음으로 나타내는 위치를 찾아서 해당 위치를 반환, 존재 안하면 0 반환 (시작 인덱스는 1)

# 문자열 길이
LENGTH(str)

• 특정 문자열 사용

  # 필드의 문자열 중 첫번쨰 문자부터 두번쨰 문자까지만 추출한다.
  SUBSTRING(PRODUCT_CODE, 1, 2)
  LEFT(PRODUCT_CODE, 2)
  REPLACE(str, 바꾸고 싶은 문자, 바꿀 문자)
  TRIM(제거하고 싶은 문자열 FROM str)
  UPPER(대문자로 바꾸고 싶은 문자열)
  LOWER(소문자로 바꾸고 싶은 문자열)

• 문자열 합치기 식별자 사용 x ; CONCAT() 식별자 사용 o ; CONCAT_WS('식별자', ...)

  SELECT CONCAT_WS(" ", Address, PostalCode, City) AS Address
  FROM Customers;

숫자 데이터

• 숫자 조작 ROUND(값, 반올림 결과 자릿수) : 반올림 CEIL(값, 올림 결과 자릿수) : 올림 FLOOR(값, 내림 결과 자릿수) : 내림 TRUNCATE(값, 버릴 자릿수) : 버림 POW([숫자],지수) : 제곱 SQRT([숫자]) : 제곱근

윈도우 함수

• 순위 메기기 / 범위 자르기에 같이 사용됨. RANK() OVER ~ PARTITION BY()
  • RANK() 대신, SUM() 등의 함수로 대체 가능. DENSE_RANK() : 공동 순위 반영.

    SELECT
    department_id,
    employee_id,
    salary,
    RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS salary_rank // 급여 순으로 순위 메기기 
    FROM
    employees;

SQL 핵심 개념

서브 쿼리

*서브 쿼리 내부에 ORDER BY문 사용 불가능.

• 단일 행 서브쿼리 : 쿼리 실행 결과가 항상 1건 이하인 경우.
• 다중 행 서브쿼리 : 결과가 2개 이상인 경우. -> IN, ALL, ANY, EXISTS를 함께 사용 !!
• FROM 서브쿼리

  # 단일 행 서브쿼리
  SELECT * FROM A WHERE AGE = (SELECT MAX(AGE) FROM A)
  

다중 행 서브쿼리

SELECT * FROM A WHERE AGE > ANY (SELECT AGE FROM A)

JOIN (SELECT ...) ON ~

SELECT USER_ID, NICKNAME,TOTAL_SALES FROM USED_GOODS_USER as a JOIN (SELECT SUM(PRICE) AS TOTAL_SALES, WRITER_ID FROM USED_GOODS_BOARD WHERE STATUS = 'DONE' GROUP BY WRITER_ID HAVING TOTAL_SALES >= 700000 ORDER BY TOTAL_SALES ) as b ON a.USER_ID = b.WRITER_ID

### 다양한 SQL 구문
1. **IF문**
- IF(조건문, 참일 때 값, 거짓일 때 값)
- IFNULL(컬럼명, 대체하고 싶은 값)

2. **WITH RECURSIVE 구문**
- 테이블 생성에 사용됨
```sql
WITH RECURSIVE [원하는 테이블명] AS (
    SELECT [초기값] AS [원하는 컬럼명]
    UNION ALL

    SELECT [원하는 컬럼명] + 1
    FROM [원하는 테이블명]
    WHERE [원하는 컬럼명] < [원하는 컬럼 개수]
)

3. WITH 구문

• 서브쿼리 정의할 때 사용됨

  WITH [원하는 테이블명] AS (
    SELECT ...
  )

[예시] 특정 조건을 만족하는 그룹 ROW 뽑기

SELECT *
FROM [테이블명] AS A
WHERE [컬럼명] = (SELECT MAX([컬럼명])
                FROM [테이블명] AS B
                WHERE A.[그룹 컬럼명] = B.[그룹 컬럼명])

[참고] SQL Join의 종류

기준에 따라 가장 좋은 것을 선택하는 알고리즘

1. '가장 큰 순서대로' 등의 기준을 은연 중에 제공해줌. -> 정렬 알고리즘과 짝을 이룸.
2. 문제 풀이를 위한 최소한의 아이디어 떠올리기 -> 정당성 검토 -> 안되면, DP 또는 그래프 알고리즘 고려해보기

구현

풀이를 떠올리는 것은 쉽지만 소스코드로 옮기기 어려운 문제 예 : 완전 탐색, 시뮬레이션

# 상하좌우 이동 문제
n = int(input())
x,y = 1,1
plans = input().split()

dx=[0,0,-1,1]
dy=[-1,1,0,0]
move_types=['L','R','U','D']

for plan in plans:
    # 이동 후 좌표 구하기
    for i in range(len(move_types)):
        if plan == move_types[i]:
            nx = x+dx[i]
            ny = y+dy[i]
    # 공간을 벗어나는 경우 무시
    if nx < 1 or ny < 1 or nx > n or ny > n:
        continue
    # 이동 수행
    x, y = nx, ny

print(x,y)

# 왕실의 나이트 문제
input_data = input()
row = int(input_data[1])
column = int(ord(input_data[0]))-int(ord('a'))+1

# 나이트가 이동할 수 있는 8가지 방향 정의
steps = [(-2,-1), (-1,-2), (1,-2), (2,-1), (2,1), (1,2), (-1,2), (-2,1)]

result = 0
for step in steps:
    # 이동하고자 하는 위치 확인
    next_row = row + step[0]
    next_column = column + step[1]
    if next_row >= 1 and next_row <= 8 and next_column >= 1 and next_column <= 8:
        result += 1

print(result)

DFS/BFS

스택, 큐, 재귀함수 개념 이용

DFS (깊이 우선 탐색) : 그래프에서 깊은 부분을 먼저 탐색하는 알고리즘.

• 스택, 재귀함수 이용

  def dfs(graph, v, visited):
    # 현재 노드를 방문 처리
    visited[v]=True
    # 현재 노드와 연결된 다른 노드를 재귀적으로 방문
    for i in graph[v]:
        if not visited[i]:
            dfs(graph,i,visited)
  

2차원 리스트로 graph 표현

노드 개수 + 1 개의 요소

graph = [ [], [2,3,8], [1,7] ]

visited = [False]*3

dfs 함수 호출

dfs(graph,1,visited)

BFS (너비 우선 탐색) : 가까운 노드부터 탐색하는 알고리즘.
- 큐 이용
```python
from collection import deque

def bfs(graph, start, visited):
    queue=deque([start])
    visited[start]=True

    # 큐가 빌 때까지 반복
    while queue:
        v = queue.popleft()
        for i in graph[v]:
            if not visited[i]:
              queue.append(i)
              visited[i]=True

# 2차원 리스트로 graph 표현
# 노드 개수 + 1 개의 요소
graph = [ [], [2,3,8], [1,7] ]

visited = [False]*3

# bfs 함수 호출
bfs(graph,1,visited)

cf. 탐색 문제는 그래프 형태로 표현한 후 풀이하자 ! - 연결된 덩어리 파악 => dfs - 가능한 최소 경로 탐색 => bfs

정렬

1. 선택 정렬

• 리스트 첫 요소부터 비교 시작.
• 비교 후, 매번 가장 작은 요소를 선택해서 맨 앞으로 보낸다.

  array=[13,2,5,259,1]
  for i in range(len(array)):
    min_index=i
    for j in range(i+1,len(array):
        if array[i] > array[j]:
            min_index=j
    # 스왑핑 !
    array[i], array[min_index] = array[min_index], array[i]

2. 삽입 정렬

• 필요할 때만 위치 변경 -> 데이터가 거의 정렬 되어 있을 때, 효율적.
• 첫 요소는 정렬되어 있다고 판단 -> 두번째 요소부터 시작.
• 오른쪽으로 이동하면서 그 이전 요소들 사이에 해당 요소를 끼워넣음.

  array=[13,2,5,259,1]
  for i in range(1,len(array)):
    # 인덱스 i부터 -1까지 감소하며 반복 !
    for j in range(i,0,-1):
        if array[j] < array[j-1] :
            array[j], array[j-1] = array[j-1], array[j]
        else:
            # 자신보다 작은 요소를 만나면 그 위치에서 멈춤 !!
            break

3. 퀵 정렬

• 병합 정렬처럼 처리 속도가 빠른 편.

• 리스트의 첫 요소를 '피벗'으로 설정 -> 피벗보다 작은 부분, 큰 부분으로 나누기 위해 요소들을 교환함.

• ( -> <- ) 방향으로 대소 비교

• 이후, 부분 부분으로 나눈 것들도 똑같은 방법으로 정렬하자.

  array=[13,2,5,259,1]
  def quick_sort(array, start, end):
    if start >= end:
        return
    pivot = start
    left = start + 1
    right = end
    while left <= right:
        while left <= end and array[left] <= array[pivot]:
            left += 1
        while right <= start and array[right] >= array[pivot]:
            right -= 1
        if left > right:
            array[pivot], array[right] = array[right], array[pivot]
        else:
            array[left], array[right] = array[right], array[left]
  
    # 분할 이후 왼쪽 부분과 오른쪽 부분에서 각각 정렬 수행
    quick_sort(array, start, right-1)
    quick_sort(array, right+1, end)
  

end는 인덱스니까 (리스트 길이 -1)으로 지정 !

quick_sort(array,0,len(array)-1)

4. 계수 정렬
- 데이터 크기 범위가 '정수 형태'로 표현할 수 있을 때만 사용 가능
- 최대 데이터 - 최소 데이터 <= 1,000,000일 때 효과적.
- 모든 범위를 담을 수 있는 크기의 리스트를 선언 !
```python
array=[13,2,5,259,1]
# 초기화 리스트 선언
count=[0]*(len(array)+1)

for i in range(len(array)):
    count[array[i]] += 1

for i in range(len(range)):
    for j in range(range[i]):
        # 띄어쓰기를 구분으로, 등장한 횟수만큼 인덱스 출력 ~!
        print(i, end=' ')

5. 정렬 라이브러리

• 퀵 정렬보다 빠름.
• 문제의 별도의 요구가 없을 경우에 사용하는 방법

  array=[13,2,5,259,1]
  array_1=[('바나나',2),('사과',5),('당근',3)]
  

1

result = sorted(array)

2

array.sort()

3

key를 기준으로 정렬

def setting(data): return data[1] result = sorted(array_1, key=setting)

### 이진 탐색
- 요소들이 정렬되어 있을 경우에, 빠르게 데이터 탐색 가능 !!
- 찾으려는 데이터와 중간점 위치에 있는 데이터를 반복적으로 비교하는 알고리즘.
- 이진 탐색 트리에서도 이용됨.
```python
def binary_search(array,target,start,end):
    if start > end:
        return None
    mid = (start+end)//2
    if array[mid] == target:
        return mid
    elif array[mid] > target:
        return binary_search(array,target,mid+1,end)
    else:
        return binary_search(array,target,start,mid-1)

result = binary_search(array, target, 0, n-1)
if result == None:
    print("존재하지 않는 원소임")
else:
    # target이 리스트의 몇 번째에 존재하는 지 ?
    print(result-1)

• 파라메트릭 서치 유형의 문제가 대표적임.
  • 최적화 문제를 결정 문제로 바꾸어 해결 ! (예. 원하는 조건을 만족하는 가장 알맞은 값을 찾는 문제)

DP

DP 풀이 문제의 조건

1. 큰 문제를 작은 문제로 나눌 수 있다.
2. 작은 문제에서 구한 정답은 그것을 포함하는 큰 문제에서도 동일하다.
3. 완전 탐색으로 했을 때 시간이 매우 오래 걸린다.

DP 풀이 방법 1. 재귀 함수 이용 (탑다운) 2. 반복문 이용 (보텀업) ‼️

메모리제이션 기법 예시.

• DP 탑다운의 경우 -> 리스트에 결과 저장.
• '수열'처럼 연속적이지 않은 값의 경우 -> dict 자료형에 결과 저장.

# 적은 금액부터 큰 금액까지 확인 -> 차례대로 만들 수 있는 최소한의 화폐 개수 찾는 문제.
n,m = map(int, input().split())
array = []
for i in range(n):
    array.append(int(input()))

# 보텀업 방식
d = [10001] * (m+1)
d[0] = 0

# ( 만들고자 하는 금액 - 화폐 단위들 )을 각각 계산하여 DP 테이블에 저장. 
for i in range(n):
    for j in range(array[i], m+1):
        if d[j-array[i]] != 10001:
            d[j-array[i]]=min(d[j-array[i]]+1, d[j])

if d[m] == 10001:
    print(-1)
else:
    print(d[m])

최단 경로

1. 다익스트라 알고리즘

• 특정 노드에서 다른 노드로 가는 각각의 최단 경로를 구해주는 알고리즘
• '음의 간선'이 없어야 함
• 그리디 알고리즘에 포함됨 : 해당 노드와 연결되어 있으면서, 방문하지 않은 노드 중 최단 거리가 가장 짧은 노드를 매번 선택 ! -> 최단 거리 갱신
• 힙 자료 구조 (우선순위 큐) 사용 -> (거리, 노드)로 저장. -> 자동으로 정렬됨.

import heapq
import sys
input = sys.stdin.readline
INF = int(1e9)

n,m = map(int, input().split())     # 노드 개수, 간선 개수
start = int(input())
graph = [[] for i in range(n+1)]
distance = [INF] * (n+1)    # 최단 거리 테이블 초기화

for _ in range(m):
    a,b,c = map(int, input().split())
    graph[a].append((b,c))

def dijkstra(start):
    q = []
    heapq.heappush(q,(0,start))
    distance[start]=0
    while q:
        dist, now = heapq.heappop(q)
        # 현재 노드가 이미 처리된 적이 있는 노드라면 무시
        if distance[now] < dist:
            continue
        for i in graph[now]:
            cost = dist + distance[i]
            if cost < distance[i[0]]:
                distance[i[0]] = cost
                heapq.heappush(q,(cost,i[0]))

dijkstra(start)

# 모든 노드로 가기 위한 최단 거리 출력
for i in range(1, n+1):
    if distance[i] == INF:
        print("무한")
    else:
        print(distance[i])    

2. 플로이드 워셜 알고리즘

• 모든 지점에서 다른 모든 지점까지의 최단 경로를 모두 구해야 하는 경우
• DP 알고리즘에 포함됨.
• 3중 반복문으로 'A->B로 가는 최소 비용'과 'A->K->B로 가는 비용'을 비교 !!
• 노드의 개수가 적을 때 사용 가능.

INF = int(1e9)

n=int(input())
m=int(input())
graph=[[INF]*(n+1) for _ in range(n+1)]

# 자기 자신 -> 자기 자신으로 가는 비용은 0으로 초기화
for a in range(1,n+1):
    for b in range(1, n+1):
        if a==b:
            graph[a][b] = 0

# 각 간선에 대한 정보를 입력 받아, 그 값으로 초기화
for _ in range(m):
    a,b,c = map(int, input().split())
    graph[a][b] = c

# 점화식에 따라 알고리즘 수행
for k in range(1,n+1):
    for a in range(1,n+1):
        for b in range(1,n+1):
            graph[a][b]=min(graph[a][k]+graph[k][b], graph[a][b])

# 수행된 결과 출력
for a in range(1,n+1):
    for b in range(1,n+1):
        if graph[a][b] == INF:
            print("무한")
        else:
            print(graph[a][b], end=" ")
    print()

그래프 이론

1. 트리를 이용해 서로소 집합 구하는 알고리즘

• union 연산을 반복 수행 -> 노드들의 연결성 파악 -> 서로소 집합 구하기
• union 연산 : 각각 루트 노드 찾기 -> 번호가 큰 노드가 작은 노드를 가리키도록 연결
• '경로 압축 기법'을 사용하여 루트 노드를 찾는 과정을 최적화함.

  def find_parent(parent,x):
  #    if parent[x] != x:
  #        return find_parent(parent,parent[x])
  #    return x
    # 경로 압축 기법 사용
    if parent[x] != x:
        parent[x] = find_parent(parent,parent[x])
    return parent[x]
  

def union_parent(parent, a, b): a = find_parent(parent, a) b = find_parent(parent, b) if a < b: parent[b] = a else: parent[a] = b

입력받기

v,e = map(int, input().split()) parent = [0] * (v+1)

parent 테이블에서 자기 자신으로 초기화

for i in range(1,v+1): parent[i]=i

union 연산 수행

for i in range(e): a,b = map(int, input().split()) union_parent(parent,a,b)

집합 출력

for i in range(1,v+1): print(find_parent(parent,i),end=" ")

print()

부모 테이블 내용 출력

for i in range(1,v+1): print(parent[i], end=" ")

- 무방향 그래프 내에서 **사이클을 판별**할 때 사용됨.
```python
# 부모노드를 자기 자신으로 초기화하는 것까지 동일.
cycle = False  # 사이클 발생 여부

for i in range(e):
    a,b = map(int, input().split())
    if find_parent(parent,a) == find_parent(parent,b):
        cycle=True
        break
     else:
         union_parent(parent,a,b)

if cycle:
    print("사이클 발생")
else:
    print("사이클 발생하지 않음")

2. 최소한의 비용으로 신장 트리를 찾는 알고리즘

• 신장 트리 : 모든 노드를 포함하면서 사이클이 존재하지 않는 부분 그래프
• 크루스칼 알고리즘 ! : 모든 간선에 대하여 정렬 -> 가장 거리가 짧은 간선부터 집합에 포함시키기 (사이클이 발생하지 않는 것만 !!)
• 최소 신장 트리에 포함되는 간선의 비용 합 = 총 비용

  # 부모노드를 자기 자신으로 초기화하는 것까지 동일.
  edges = []  # 모든 간선을 담을 변수
  result = [] # 총 비용을 담을 변수
  

for _ in range(e): a,b,cost = map(int, input().split()) edges.append((cost,a,b))

edges.sort() # 비용순으로 정렬

간선 하나씩 확인

for edge in edges: cost, a, b = edge # 튜플 if find_parent(parent,a) != find_parent(parent,b): union_parent(parent,a,b) result += cost

print(result)

3. **위상 정렬**을 사용하여 **방향 그래프를 순서대로 나열**하는 알고리즘
- 진입 차수 : 특정한 노드로 '들어오는' 간선의 개수
- 위상 정렬 알고리즘 : 진입 차수가 0인 노드를 큐에 삽입 -> 큐가 빌 때까지, 꺼낸 노드에서 출발하는 간선을 그래프에서 제거 + 새롭게 진입차수가 0이 된 노드를 큐에 삽입
- 모든 원소를 방문하기 전에 큐가 빈다 ? = 사이클 발생 !!!!!

```python
from collections import deque

v,e = map(int,input().split())
# 모든 노드에 대해 진입 차수를 0으로 초기화
indegree = [0] * (v+1)
graph = [ [] for i in range(v+1) ]

# 방향 그래프의 모든 간선 정보를 입력받기
for _ in range(e):
    a,b = map(int, input().split())
    graph[a].append(b)  # a에서 b로 이동 가능 !!!!!
    indegree[b] += 1

# 위상 정렬 함수
def topology_sort():
    result = []
    q=deque()

    for i in range(1,v+1):
        if indegree == 0:
            q.append(i)

    while q:
        now = q.popleft()
        result.append(now)
        # 해당 원소와 연결된 모든 노드들의 진입차수 -1
        for i in graph[now]:
            indegree[i] -= 1
            if indegree[i] == 0:
                q.append(i)

    # 위상 정렬 결과 출력
    for i in result:
        print(i, end=" ")

topology_sort()

내끼니끼 🍚

• 소액씩 모으고 한 달에 한 번 모은 돈 직접 기부 - 결제 API
• 목표 금액 설정해서 금액 채워지면 기부
• 기부 시 기부하고싶은 분야 골라서 사이트 연결
• 끼니별 금액 설정 / 끼니에 지출한 금액의 일정 비율
• 지출 금액 파악 방법 : 직접 작성
• 기부 내역 정리, 기부한 만큼 기여한 끼니정도 보여주기
• 기부정도에 따라 뱃지/기부 온도 표시해주기
• 모인 금액 밥그릇으로 보여주기

우리가 풀어야 하는 문제들

1. 블록체인 구현
2. 기부 캠페인 리스트업
   • 네이버 검색 api -> '결식아동후원' 검색어 결과 중 기부 검색 키워드의 내용 크롤링
3. 메인 기능의 임팩트 부족
   • '기부'로 이어지기 전 과정에서의 부자연스러움 존재

Solution Challenge 여정을 담은 시리즈의 시작으로, 아이디어를 결정하기까지의 과정을 말해보려고 한다.

1. 프로젝트 마감일까지 시간이 빠듯하다. -> 근데 백엔드는 나 혼자다. -> 백엔드 기능 구현에서 개발 시간 단축 필요
2. 팀원들 모두 플러터를 처음 배우는 것임. -> 기술스택이 익숙하지 않은 상황에서, UI 구현만으로도 프론트 작업 시간이 많이 소요될 것으로 예상
3. 나를 제외한 팀원들은 팀플 경험이 없음. -> 본인이 백엔드랑 api 통신까지 구현하려면 기본적인 플러터 사용 방법 + 플러터 인증 시스템 등을 공부해야 함

백엔드와 배포를 담당한 나는 프레임워크를 고민하다가, 기본적인 CRUD부터 authentication까지 많은 유틸리티를 제공하기도 하고, 프론트와 api 연결, DB 생성까지 비교적 쉽고 빠르게 할 수 있는 'Django'로 결정 !

프론트엔드 - Flutter 백엔드 - Django 배포 - GCP

Idea Brainstorming

최종 아이디어를 향한 방황

구글이 제시한 17개의 목표를 해결할 수 있는 서비스를 제안하면 되는 건데,

1. 저소득층 혜택관리 서비스 🔍
   • 사용자 정보 입력 -> 해당되는 정부 지원 / 혜택 정리
   • 정부 24 기능과의 차별성 필요
2. Zero Waste 격려 서비스
3. 소상공인을 위한 협업 플랫폼 🔍
   • 주변 동종업계 가게들과의 협업 서비스 (재료 공동구매, 공동 고객관리 등)
   • 사장님 발주 도우미 (발주 자동화, 발주 일정 관리 등) ⏺ ex. 업체 번호로 발주 문자 자동 발송
4. 어르신들을 위한 교육 플랫폼
5. 수업진행도 관리 서비스

나는 🔍로 표시한 아이디어들을 제안했고, 팀원들과의 회의 결과, 크게 5가지 아이디어로 정리가 되었다.

이 중에 zero waste가 구글이 제시한 목표와 연관성도 높고 주제로서 시의성, 관심도가 높은 것 같아서 'Zero Waste Kitchen' (이하 Zero Kitchen)으로 서비스 방향을 잡았다.

Zero Kitchen 기능 ❗️

• 유통기한 또는 구매 순으로 정렬
• 유통기한 임박한 재료로 만들 수 있는 음식 추천
• 유통기한이 지난 음식을 활용할 수 있는 방법 찾아주기

Zero Kitchen 목표 ❗️

• 음식물 쓰레기 감소
• 과도한 소비 막기
• 식재료 낭비 없이 오래 먹는 친환경 식생활 촉진

피그마 - Zero Kitchen 프로토타입

노션 - Zero Kitchen 페이지별 기능 구체화

하지만, 아이디어 발표에서 큰 ❌혹평❌을 받게 되는데...

1. 냉장고 항목 하나하나 등록 굉장히 비효율
2. 수많은 냉장고 관리 앱과의 차별점이 필요
3. 앱 서비스를 통해 재활용을 쉽게 도와줄 수 있는 방법이 있으면 좋겠다
4. 굳이 냉장고에만 신경쓰지 마라
5. 기존 앱에 다 구현되어 있는데 왜 사람들이 안쓰는지 생각해봐라
6. 가정집 냉장고가 아니라 식당 냉장고 관리에 앱을 사용할 수도 있다

피드백을 듣고, UX 관점에서 서비스의 사용성과 가치, 발전 가능성을 냉정하게 생각해봤다. 오랜 회의 끝에.... 위 아이디어를 버리기로 결정했다. '새로운 아이디어가 낫겠다'는 결론에 도달했기 때문 !

또 다시 처음으로..!

좋아. 처음부터 다시 시작해보자. 도르마무 도르마무... 끝없는 아이디어 회의 지옥...

1. 기부 - 음식

• 내 끼니 기부하기
• 고객 혜택/참여율 증진 - 퍼센트를 설정해서 일부는 적금 일부는 기부
• 달마다 기부 금액이 어떻게 쓰였는지 식사 관련 형태로 알려줌

2. 음주 관리 앱 기존 서비스에서 추가해서 만들었으면 하는 것

• 적정 음주량 가이드라인 제공
  • 통계로 알코올중독 진단 결과 제공 (자가진단 리스트 이용)
• 목표 설정
  • 적정량 (또는 그 이하)에 가까워지도록 목표 설정
  • 월/주 n회 + 일 n잔/n병
  • 이전 주에 비해 덜 마신 만큼 칼로리/비용 등... 감소했다는 표시

3. 응급실 콜 🔍

• 사용자 타겟팅: 응급실에서 근무하는 전공의들 대상
• 병원 교수님들 위치 확인, 제일 가까운 의사한테 콜
• 119 신고 정보랑 연결해서 의사들한테 알림 가게 하기

-> 교수님들의 예상 도착 시간 알 수 있게 함

이 중에 '식사 기부' 아이디어를 최종적으로 선택했다 ! 서비스 이름은 '내끼니끼🍚' !!! 제법 귀엽 ㅎ

다음엔 '아이디어 구체화' 편으로 돌아오겠다.

스프링 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크. 즉, 인증(Authenticate, 누구인지?) 과 인가(Authorize, 어떤것을 할 수 있는지?)를 담당하는 프레임워크를 말함.

스프링 시큐리티에서는 주로 서블릿 필터(filter)와 이들로 구성된 필터체인으로의 구성된 위임모델을 사용함. 그리고 보안과 관련해서 체계적으로 많은 옵션을 제공해주기 때문에 개발자 입장에서는 일일이 보안관련 로직을 작성하지 않아도 된다는 장점이 있음.

기본용어

• 접근 주체(Principal) : 보호된 리소스에 접근하는 대상
• 인증(Authentication) : 보호된 리소스에 접근한 대상에 대해 누구인지, 애플리케이션의 작업을 수행해도 되는 주체인지 확인하는 과정(ex. Form 기반 로그인) => 즉, 누구인지?
• 인가(Authorize) : 해당 리소스에 대해 접근 가능한 권한을 가지고 있는지 확인하는 과정(After Authentication, 인증 이후) => 즉, 어떤 것을 할 수 있는지?
• 권한 : 어떠한 리소스에 대한 접근 제한, 모든 리소스는 접근 제어 권한이 걸려있음. 인가 과정에서 해당 리소스에 대한 제한된 최소한의 권한을 가졌는지 확인

💡 스프링 시큐리티 특징과 구조

• 보안과 관련하여 체계적으로 많은 옵션을 제공하여 편리하게 사용할 수 있음
• Filter 기반으로 MVC와 분리하여 관리 및 동작
  • 어노테이션을 통한 간단한 설정
  • Spring Security는 기본적으로 **세션 & 쿠키방식으로 인증
  • *

• 인증관리자(Authentication Manager)와 접근 결정 관리자(Access Decision Manager)를 통해 사용자의 리소스 접근을 관리 ( 인증 관리자는 UsenamePasswordAuthenticationFilter, 접근 결정 관리자는 FilterSecurityInterceptor가 수행 )

💡 스프링시큐리티 기본구조

📌 각 필터별 기능 설명

*기능 *

1) 파일 관리 자동화 2) 버전 관리

S3를 이용해서 내 파일 안전하게 보관하기!

구성 요소

1) 버킷 예) 하나의 프로젝트

2) 폴더

3) 오브젝트 (파일)

1. 버킷 생성

2. AWS IAM 생성

3. 로컬 환경에서 이미지, 동영상 업로드하기

build.gradle < 주요 사용 라이브러리 >

spring-cloud-starter-aws spring-boot-starter-web lombok Thymleaf

➕ S3UploaderService.java

• S3에 정적 파일을 올리는 기능

[[AWS] Springboot에 AWS S3 연동 (이미지, 동영상 업로드)] (https://develop-writing.tistory.com/m/128)에서 자세한 코드 참고 !

• MultipartFile 전달받음.
• S3에 전달할 수 있도록 MultiPartFile을 File로 전환 및 저장. (S3에 Multipartfile 타입은 전송이 안되기 때문)
• 전환된 File을 S3에** public 읽기 권한**으로 업로드. (외부에서 정적 파일을 읽을 수 있도록 하기 위해)
• 로컬에 생성된 File 삭제. (Multipartfile -> File로 전환됨)
• 업로드된 파일의 S3 URL 주소를 반환

여기서 특이한 부분은 별다른 Configuration 코드 없이 AmazonS3Client 를 DI 받은것인데요. Spring Boot Cloud AWS를 사용하게 되면 S3 관련 Bean을 자동 생성해줍니다.

-> 그래서 AmazonS3, AmazonS3Client, ResourceLoader는 직접 설정할 필요 X

💡 basicDir, fileDir는 *Profile별 저장될 파일 경로 *!

• 로컬에서 테스트할 경우 {프로젝트 경로}/resource/static/files 경로에 파일을 저장할 수 있게 하기 위해 !

• EC2에서 테스트할 경우 /home/ec2-user/files 에 저장이 될 것임.

➕ S3UploaderController.java

• 4가지 기능 1) image-upload 웹 페이지 반환 2) video-upload 웹 페이지 반환 3) data로 넘어오는 이미지 MultipartFile을 S3UploaderService로 전달 4) data로 넘어오는 동영상 MultipartFile을 S3UploaderService로 전달

➕ AWS S3에 필요한 정보를 application.yml에 추가

spring:
  profiles:
    group:
      "local": "local, common"
      "development": "development,common"
    active: local

---
# 공통
spring:
  config:
    activate:
      on-profile: "common"
  servlet:
    multipart:
      max-file-size: 1GB
      max-request-size: 1GB

# s3에 필요한 정보
cloud:
  aws:
    region:
      static: ap-northeast-2
    s3:
      bucket: 1-source
    stack:
      auto: false  // EC2에서 Spring Cloud 프로젝트를 실행시키면 기본으로 CloudFormation 구성을 시작함. 
                   // 설정한 CloudFormation이 없으면 프로젝트 시작이 안되기 때문에 해당 내용을 사용하지 않도록 false를 등록합니다.

logging:
  level:
    com:
      amazonaws:
        util:
          EC2MetadataUtils: error

---
# 로컬 환경
spring:
  environment: "local"
  config:
    activate:
      on-profile: "local"
  file-dir: /src/main/resources/static/files/
---
# 배포 환경
spring:
  environment: "development"
  config:
    activate:
      on-profile: "development"
  file-dir: /home/ec2-user/files/

➕ aws.yml AWS User의 access-key와, secret-key는 탈취되는 문제를 예방하기 위해 추가. 그리고 .gitignore에 aws.yml 코드 추가하기 !

cloud:
  aws:
    credentials:
      access-key: 발급받은 access-key
      secret-key: 발급받은 secret-key

➕ S3uploaderApplication.java에 아래 코드 추가 !

public static final String APPLICATION_LOCATIONS = "spring.config.location="
            + "classpath:application.yml,"
            + "classpath:aws.yml";

➕ 프로파일 별로 파일이 저장될 폴더를 만들기 위해 스프링 부트가 시작할 때 폴더를 만드는 코드 추가

/**
     * @description 이미지, 영상 업로드할 폴더를 프로파일 별로 다른 경로에 생성한다.
     */
    @PostConstruct
    private void init() {

        if (environment.equals("local")) {
            String staticFolder = System.getProperty("user.dir") + "/src/main/resources/static";
            mkdirResource(staticFolder);

            String files = System.getProperty("user.dir") + fileDir;
            mkdirResource(files);
        } else if (environment.equals("development")) {
            String filesFolder = "/var/www/html/files";
            mkdirResource(filesFolder);
        }
    }

    /**
     * @param fileDir 생성을 위한 폴더명
     * @description 주어진 경로에 폴더를 생성함
     */
    private static void mkdirResource(String fileDir) {
        File Folder = new File(fileDir);

        // 해당 디렉토리가 없을경우 디렉토리를 생성합니다.
        if (!Folder.exists()) {
            try {
                Folder.mkdir(); //폴더 생성합니다.
            } catch (Exception e) {
                e.getStackTrace();
            }
        }
    }

➕ 마지막으로 VM options에 아래 코드 추가 !

Dcom.amazonaws.sdk.disableEc2Metadata=true

( EC2에서 실행해주기 위해 )

주문 조회 v1. 엔티티 직접 노출

@GetMapping("/api/v1/orders")
public List<Order> ordersV1() {
    List<Order> all = orderRepository.findAll();
    // 직접 초기화 시키기
    for (Order order : all) {
        order.getMember().getName(); 
        order.getDelivery().getAddress(); 
        List<OrderItem> orderItems = order.getOrderItems(); 
        orderItems.stream().forEach(o -> o.getItem().getName()); // 오더아이템도 직접 초기화
    }
    return all;
}

엔티티를 직접 노출하는 것은 좋지 않음 !

주문 조회 v2. 엔티티를 DTO로 변환

@GetMapping("/api/v2/orders")
public List<OrderDto> ordersV2() {
      List<Order> orders = orderRepository.findAll();
      List<OrderDto> result = orders.stream()
              .map(o -> new OrderDto(o))
              .collect(toList());
      return result;
}

OrderApiController

@Data
static class OrderDto {
    private Long orderId;
    ...
    // 생성자
    public OrderDto(Order order) {
        // 초기화
        orderId = order.getId();
        name = order.getMember().getName();
        ...
        orderItems = order.getOrderItems().stream()
                  .map(orderItem -> new OrderItemDto(orderItem))
                  .collect(toList());
    }
}
@Data
static class OrderItemDto {
    private String itemName;//상품 명
    private int orderPrice; //주문 가격 
    private int count; //주문 수량
    ...
}

지연 로딩으로 너무 많은 SQL이 실행됨. SQL 실행 수 : 1+N

주문 조회 v3. 페치 조인 최적화

@GetMapping("/api/v3/orders")
public List<OrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithItem();
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(toList());
        return result;
}

OrderRepository

public List<Order> findAllWithItem() {
    return em.createQuery(

        "select distinct o from Order o" +
            " join fetch o.member m" +
            " join fetch o.delivery d" +
            " join fetch o.orderItems oi" +
            " join fetch oi.item i", Order.class)
        .getResultList();
}

📍** distinct를 쓰는 이유?**

• 컬렉션을 페치 조인하면 일대다 조인이 발생하는데,
• 데이터는 다(N)를 기준으로 row 가 생성되기 때문에*
• *같은 엔티티가 중복 조회된다.
• *
• Order를 기준으로 페이징 하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어버리면서 발생하는 문제 !

-> Order을 기준으로 제시하면서 중복을 제거해주기 위해 distinct 추가해줌

💡 SQL 1번만 실행됨

• sql과 다르게 JPA에서는 id값이 같으면 중복처리 해주기 때문에 페치 조인으로 인해 쿼리가 1번 조회됨 !

💡 페이징 불가능

• 1:N 연관관계인 두 엔티티가 즉시 로딩된다면 (엔티티 그래프나 fetch join 으로 연결되어 있다면) 페이징 처리시 쿼리에 limit 가 붙지 않고 모든 데이터를 메모리에 불러오기 때문 !

▪️ 페이징? 예: 원하는 페이지 값과 사이즈를 넣어 데이터를 조회하는 것. 예를 들어 page=0, size=10 이면 첫번째 페이지의 주문 10개 결과가 나오게 된다.

페이징과 한계 돌파

페이징과 컬렉션 엔티티를 함께 조회하는 방법은?

• 1️⃣ ToOne(OneToOne, ManyToOne) 관계를 모두 페치조인 (row수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 X)
• 2️⃣ 컬렉션은 지연 로딩으로 조회
• 3️⃣ applications.yml에 설정 추가 or @BatchSize 사용 (for 지연로딩 성능 최적화)

  spring: jpa:
    properties:
        hibernate:
            default_batch_fetch_size: 1000

  -> 주문 id 를 마지막쿼리의 in 절에 넣어 해당 주문상품만 가져오게 되는 구조 !

OrderRepository

    public List<Order> findAllWithMemberDelivery(int offset, int limit) {
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" +
                        " join fetch o.delivery d", Order.class
        ).setFirstResult(offset)
                .setMaxResults(limit)
                .getResultList();
    }

OrderApiController

@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_page(@RequestParam(value = "offset",
  defaultValue = "0") int offset,
                                      @RequestParam(value = "limit", defaultValue
  = "100") int limit) {
      List<Order> orders = orderRepository.findAllWithMemberDelivery(offset,limit);
      List<OrderDto> result = orders.stream()
              .map(o -> new OrderDto(o))
               .collect(toList());

      return result;
 }

1️⃣ 쿼리 호출 수가 1+N -> 1+1로 최적화됨. 2️⃣ 조인보다 DB 데이터 전송량이 최적화 됨. (페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.) ❗️ why ? IN절에 객체 담아서 한번에 보내기 때문! 3️⃣ 페이징 가능

주문 조회 V4: JPA에서 DTO 직접 조회

엔티티는 리포지토리, 화면이나 API에 의존관계가 있는 쿼리는 따로 클래스를 분리 !

• 루트 1번 + 컬렉션 N 번 쿼리 실행 (컬렉션을 루프로 직접 넣어주기 때문에 N번 걸림.)

• ToOne(N:1, 1:1) 관계들을 먼저 조회하고, ToMany(1:N) 관계는 각각 별도로 처리 ( row 수가 증가하지 않는 ToOne 관계는 조인으로 최적화 하기 쉬우므로 한번에 조회하고, ToMany 관계는 최적화 하기 어려우므로 findOrderItems() 같은 별도의 메서드로 조회 )

주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

OrderQueryRepository

public List<OrderQueryDto> findAllByDto_optimization() { //루트 조회(toOne 코드를 모두 한번에 조회)
      List<OrderQueryDto> result = findOrders();
//orderItem 컬렉션을 MAP 한방에 조회
      Map<Long, List<OrderItemQueryDto>> orderItemMap =
  findOrderItemMap(toOrderIds(result));
//루프를 돌면서 컬렉션 추가(추가 쿼리 실행X) in절에 담아서 한번에 가져오기 
result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId())));
      return result;
}

private List<Long> toOrderIds(List<OrderQueryDto> result) {
      return result.stream()
              .map(o -> o.getOrderId())
              .collect(Collectors.toList());
}

private Map<Long, List<OrderItemQueryDto>> findOrderItemMap(List<Long>
  orderIds) {
      List<OrderItemQueryDto> orderItems = em.createQuery(
              "select new

   jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name,
  oi.orderPrice, oi.count)" +
                      " from OrderItem oi" +
                      " join oi.item i" +
                      " where oi.order.id in :orderIds", OrderItemQueryDto.class)
              .setParameter("orderIds", orderIds)
              .getResultList();
    return orderItems.stream()
        .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));
}

1️⃣ Query: 루트 1번, 컬렉션 1번 (총 2번~) 2️⃣ ToOne 관계들을 먼저 조회하고, 여기서 얻은 식별자 orderId로 ToMany 관계인 OrderItem 을 한꺼번에 조회 3️⃣ MAP을 사용해서 매칭 성능 향상(O(1)) 4️⃣ 데이터를 한꺼번에 처리할 때 많이 씀

주문 조회 V6: JPA에서 DTO로 직접 조회, 플랫 데이터 최적화

OrderQueryRepository

public List<OrderFlatDto> findAllByDto_flat() {
      return em.createQuery(
              "select new
  jpabook.jpashop.repository.order.query.OrderFlatDto(o.id, m.name, o.orderDate,
  o.status, d.address, i.name, oi.orderPrice, oi.count)" +
                        " from Order o" +
                      " join o.member m" +
                      " join o.delivery d" +
                      " join o.orderItems oi" +
                      " join oi.item i", OrderFlatDto.class)
              .getResultList();
OrderFlatDto
  package jpabook.jpashop.repository.order.query;
  import jpabook.jpashop.domain.Address;
}

1️⃣ Query: 1번 2️⃣ 쿼리는 한번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가되기 때문에 상황에 따라 V5 보다 더 느릴 수도 있음 3️⃣ 애플리케이션에서 추가 작업이 큼 4️⃣ 페이징 불가능

결론 !

간단한 주문 조회 - recommended way

◦ 1. 엔티티 조회 -> DTO로 변환

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDto> ordersV2() {
    List<Order> orders = orderRepository.findAll();
    List<SimpleOrderDto> result = orders.stream()
        .map(o -> new SimpleOrderDto(o))
        .collect(toList());
    return result;
}

지연로딩으로 쿼리 N번 호출하기 때문에 효율적이지 않아서 성능이 상황에 따라서 성능이 저하될 수 있음.

◦ 2. 엔티티 조회 -> DTO로 변환 ( fetch, join 최적화 )

@GetMapping("/api/v3/simple-orders")
public List<SimpleOrderDto> ordersV3() {
    List<Order> orders = orderRepository.findAllWithMemberDelivery();
    List<SimpleOrderDto> result = orders.stream()
        .map(o -> new SimpleOrderDto(o))
        .collect(toList());
    return result;
}

OrderRepository

public List<Order> findAllWithMemberDelivery() {
      return em.createQuery(

        "select o from Order o" +
        " join fetch o.member m" +
        " join fetch o.delivery d", Order.class)
            .getResultList();
}

쿼리 1번에 조회 가능 !

• order -> member , order -> delivery 는 이미 조회 된 상태 이므로 지연로딩 X

◦ 3. JPA에서 DTO로 바로 조회

@GetMapping("/api/v4/simple-orders")
public List<OrderSimpleQueryDto> ordersV4() {
      return orderSimpleQueryRepository.findOrderDtos();
}

쿼리 1번에 select절에서 원하는 데이터만 조회 가능 !

💡 쿼리 방식 선택 권장 순서 1. 우선 엔티티를 DTO로 변환하는 방법을 선택한다. 2. 필요하면 페치 조인으로 성능을 최적화 한다. 대부분의 성능 이슈가 해결된다. 3. 그래도 안되면 DTO로 직접 조회하는 방법을 사용한다. 4. 최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다.

❌ 잘못된 방법 ( 요청 값으로 Member 엔티티를 직접 받음. )

@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member)
{
    Long id = memberService.join(member);
    return new CreateMemberResponse(id);
}

여러 곳에서 수정될 가능성이 있는 Entity가 바뀜으로 인해서 만들어놓은 api스펙이 변경될 수 있도록 하면 안된다. -> ⭕️ API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다.

-> 파라미터로 넘어오는 값이 무엇인지 확실히 알 수 있음 ! -> 유지보수에 유리함.

@PostMapping("/api/v2/members")
public CreateMemberResponse saveMemberV2(@RequestBody @Valid
  CreateMemberRequest request) {
          Member member = new Member();
          member.setName(request.getName());
          Long id = memberService.join(member);
          return new CreateMemberResponse(id);
}

@Data
static class CreateMemberRequest {
    private String name;
}

❗️❗️ 실무에서는 엔티티를 API 스펙에 노출하면 안된다!

회원 수정 API

회원 조회와 똑같이 DTO를 요청 파라미터에 넘겨준다.

@PostMapping("/api/v2/members/{id}") // 부분 업데이트를 하려면 post나 patch를 사용하는 것이 restful한 방법.
public UpdateMemberResponse updateMemberV2(@PathVariable("id") Long id, @RequestBody @Valid UpdateMemberRequest request) {
        memberService.update(id, request.getName());
        Member findMember = memberService.findOne(id); // 커맨드와 쿼리를 구분하기 위한 코드
        return new UpdateMemberResponse(findMember.getId(), findMember.getName());
}

public class MemberService {
        private final MemberRepository memberRepository;

        // 변경 감지를 이용해서 데이터 수정함.
        @Transactional
        public void update(Long id, String name) {
            Member member = memberRepository.findOne(id);
            member.setName(name);
        }
}

회원 조회 API

🔴 다양한 API 요구에 따라서 유연하게 데이터를 주고받기 위해서 응답 값으로 엔티티를 직접 외부에 노출하지 않고, 별도의 DTO를 반환해야 한다.

@GetMapping("/api/v2/members")
public Result membersV2() {
    List<Member> findMembers = memberService.findMembers(); // 엔티티 -> DTO 변환
    List<MemberDto> collect = findMembers.stream()
        .map(m -> new MemberDto(m.getName()))
        .collect(Collectors.toList());
    return new Result(collect);  // 컬렉션을 감싸서 향후 필요한 필드 추가 가능
}
@Data
@AllArgsConstructor
static class Result<T> {
    private T data;
}

Application.yml 에서

ddl-auto:None

위 코드 추가 -> 한번 데이터를 넣어놓으면 테이블을 들어가지 않고 계속해서 db에 있는 데이터들을 쓸 수 있다.

홈 컨트롤러 등록

• SLF4J (Simple Logging Facade for Java) 란? java.util.logging, logback 및 log4j와 같은 다양한 로깅 프레임 워크에 대한 추상화(인터페이스) 역할을 하는 라이브러리

최종 사용자가 배포시 원하는 로깅 프레임워크를 결정하고 사용해도 SLF4J가 인터페이스화 되어있기 때문에, SLF4J를 의존하는 클라이언트 코드에서는 실제 구현을 몰라도 됨.

(의존관계 역전 법칙)

회원

회원 등록

• 폼 객체를 사용해서 화면 계층과 서비스 계층을 명확하게 분리하기 !!

  📍 참고: 폼 객체 (MemberForm) vs 엔티티 (Member) 직접 사용 요구사항이 정말 단순할 때를 제외하고 엔티티 (Member)를 직접 등록하면 유지보수가 어려워진다. 실무에서 엔티티는 핵심 비즈니스 로직만 가지고 있고, 화면을 위한 로직은 없어야 한다.

• 화면이나 API 요구사항을 폼 객체나 DTO로 처리*하고, 엔티티는 최대한 순수 하게 유지하자.

회원 등록 폼 객체

package jpabook.jpashop.web;
import lombok.Getter;
import lombok.Setter;
import javax.validation.constraints.NotEmpty;
@Getter @Setter
public class MemberForm {
    @NotEmpty(message = "회원 이름은 필수 입니다") private String name;
    private String city;
    private String street;
    private String zipcode;
}

회원 등록 컨트롤러

@Controller
@RequiredArgsConstructor
public class MemberController {
    private final MemberService memberService;
    @GetMapping(value = "/members/new")
    public String createForm(Model model) {
        model.addAttribute("memberForm", new MemberForm());
        return "members/createMemberForm";
    }
    @PostMapping(value = "/members/new")
    public String create(@Valid MemberForm form, BindingResult result) {
        if (result.hasErrors()) {
            return "members/createMemberForm";
}
        Address address = new Address(form.getCity(), form.getStreet(),
form.getZipcode());
        Member member = new Member();
        member.setName(form.getName());
 member.setAddress(address);
          memberService.join(member);
          return "redirect:/";
      }
}

회원 목록 조회

package jpabook.jpashop.web;

@Controller
@RequiredArgsConstructor
public class MemberController {

    //추가
    @GetMapping(value = "/members") public String list(Model model) {
    List<Member> members = memberService.findMembers();
    model.addAttribute("members", members); // 조회한 상품을 뷰에 전달하기 위해 모델 객체에 보관

    return "members/memberList"; // 실행할 뷰 이름 반환

    }
}

상품

상품 등록

상품 등록 폼은 회원 등록의 경우와 매우 유사하므로 생략.

상품 등록 컨트롤러

@Controller
@RequiredArgsConstructor
public class ItemController {
    private final ItemService itemService;
    @GetMapping(value = "/items/new")
    public String createForm(Model model) {
        model.addAttribute("form", new BookForm());
         return "items/createItemForm";
    }

    @PostMapping(value = "/items/new") // POST 요청
    public String create(BookForm form) {
        Book book = new Book();
        book.setName(form.getName());
        book.setPrice(form.getPrice());
        book.setStockQuantity(form.getStockQuantity());
        book.setAuthor(form.getAuthor());
        book.setIsbn(form.getIsbn());
        itemService.saveItem(book);
        return "redirect:/items"; // 상품 목록 화면으로 리다이렉트
    }
 }

상품 수정

@Controller
@RequiredArgsConstructor
public class ItemController {
    /**
    * 상품 수정 폼
    */
    @GetMapping(value = "/items/{itemId}/edit") // GET 요청
    public String updateItemForm(@PathVariable("itemId") Long itemId, Model
model) {
        Book item = (Book) itemService.findOne(itemId); // 준영속 상태 ( book 객체에 해당 ), 수정할 상품 조회
        BookForm form = new BookForm();
        form.setId(item.getId());
        form.setName(item.getName());
        form.setPrice(item.getPrice());
        form.setStockQuantity(item.getStockQuantity());
        form.setAuthor(item.getAuthor());
        form.setIsbn(item.getIsbn());
        model.addAttribute("form", form);
        return "items/updateItemForm";
    }

    /**
    * 상품 수정
    */
    @PostMapping(value = "/items/{itemId}/edit")  // POST 요청
    public String updateItem(@ModelAttribute("form") BookForm form) {
        Book book = new Book();
        book.setId(form.getId());
        book.setName(form.getName());
        book.setPrice(form.getPrice());
        book.setStockQuantity(form.getStockQuantity());
        book.setAuthor(form.getAuthor());
        book.setIsbn(form.getIsbn());
        itemService.saveItem(book);
        return "redirect:/items";
       }
}

변경 감지와 병합

준영속 엔티티란?

영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.

*상품 수정 코드에서처럼 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준 영속 엔티티로 볼 수 있다.

준영속 엔티티 수정하는 방법 (2)

1) ** ⭐️ ⭐️ ⭐️ 변경 감지 기능 사용 ⭐️ ⭐️ ⭐️ **

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
    Item findItem = em.find(Item.class, itemParam.getId()); //같은 엔티티를 조회한 다.
    findItem.setPrice(itemParam.getPrice()); //데이터를 수정한다. 
}

영속성 컨텍스트에서 엔티티를 다시 조회** -> 변경할 값 선택 트랜잭션 커밋 시점에 변경 감지(Dirty Checking) -> 데이터베이스에 UPDATE SQL 실행 -> 데이터 수정

권장 코드

@Controller
@RequiredArgsConstructor
    public class ItemController {
        private final ItemService itemService;
        /**
        *상품 수정,권장 코드
        */
        @PostMapping(value = "/items/{itemId}/edit")
        public String updateItem(@ModelAttribute("form") BookForm form) {
            itemService.updateItem(form.getId(), form.getName(), form.getPrice());
            return "redirect:/items";
        }
    }

@Service
@RequiredArgsConstructor

public class ItemService {
     private final ItemRepository itemRepository;
      /**
      * 영속성 컨텍스트가 자동 변경
      */
      @Transactional
      public void updateItem(Long id, String name, int price) {
          Item item = itemRepository.findOne(id);
          item.setName(name);
          item.setPrice(price);
    }
}

2) 병합 사용

1. 준영속 엔티티의 식별자 값으로 영속 엔티티 조회
2. 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체 (** = 병합** )
3. 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 DB에 UPDATE SQL이 실행됨.

@Transactional
    void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티 Item mergeItem = em.merge(item);
}

상품 주문

위의 과정과 매우 유사하므로 생략.

개발 순서 리마인드 : 엔티티 -> 레포지토리 -> 서비스

상품 레포지토리 개발

📍

public void save(Item item) {
    if (item.getId() == null) { // 새로운 회원일 때
        em.persist(item);
    }
    else {                      // DB에 이미 저장된 엔티티 '수정'
        em.merge(item);
    }
}

상품 서비스 개발

• 레포지토리 클래스에 위임만 하는 클래스 !!

2️⃣ 주문 도메인 개발

상품 도메인 개발과 방법이 유사함.

주문 검색 기능 개발

• JPA에서 동적 쿼리를 어떻게 처리해야 하는가?

1) 검색 조건으로 파라미터에 OrderSearch 클래스를 추가한다.

package jpabook.jpashop.domain;
public class OrderSearch {
    private String memberName; //회원 이름
    private OrderStatus orderStatus;//주문 상태[ORDER, CANCEL] //Getter, Setter
}

그 다음, 리포지토리 클래스에 코드 추가 !

public List<Order> findAll(OrderSearch orderSearch) { 
    //... 검색 로직
}

2) JPA Criteria로 처리

public List<Order> findAllByCriteria(OrderSearch orderSearch) {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<Order> cq = cb.createQuery(Order.class);
    Root<Order> o = cq.from(Order.class);
    Join<Order, Member> m = o.join("member", JoinType.INNER); //회원과 조인
    List<Predicate> criteria = new ArrayList<>();
    //주문 상태 검색
    if (orderSearch.getOrderStatus() != null) {
          Predicate status = cb.equal(o.get("status"),
          orderSearch.getOrderStatus());
          criteria.add(status);
    }
    //회원 이름 검색
    if (StringUtils.hasText(orderSearch.getMemberName())) {
          Predicate name = cb.like(m.<String>get("name"), "%" + orderSearch.getMemberName() + "%");
          criteria.add(name);
    }
     cq.where(cb.and(criteria.toArray(new Predicate[criteria.size()])));
    TypedQuery<Order> query = em.createQuery(cq).setMaxResults(1000); //최대 1000건
        return query.getResultList();
}

실무에서 쓰기엔 너무 복잡함. -> Querydsl 사용 !

(회원 엔티티 코드 다시 보기) ➡️ 회원 리포지토리 개발 ➡️ 회원 서비스 개발 ➡️ 회원 기능 테스트

MemberRepository

@Repository  // 스프링 빈으로 등록, JPA 예외를 스프링 기반 예외로 예외 변환
public class MemberRepository {
    @PersistenceContext  // 엔티티 메니저(EntityManager) 주입
    private EntityManager em;

      // 기능 1
    public void save(Member member) {
          em.persist(member);
    }
    // 기능 2
    public Member findOne(Long id) {
          return em.find(Member.class, id);
    }
    // 기능 3
    public List<Member> findAll() {
          return em.createQuery("select m from Member m", Member.class)
                  .getResultList();
    }
    // 기능 4
    public List<Member> findByName(String name) {
          return em.createQuery("select m from Member m where m.name = :name",
Member.class)
            .setParameter("name", name)
            .getResultList();
      }

}

cf) @PersistenceUnit : 엔티티 메니터 팩토리( EntityManagerFactory ) 주입

MemberService

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
    public class MemberService {
        private final MemberRepository memberRepository;   // 레포지토리 객체 만들기

        /**
        * 회원가입 */
        @Transactional // 변경
        public Long join(Member member) {
            validateDuplicateMember(member); // 중복 회원 검증 memberRepository.save(member);
            memberRepository.save(member);
            return member.getId();
        }

        private void validateDuplicateMember(Member member) {
            List<Member> findMembers = memberRepository.findByName(member.getName());
            if (!findMembers.isEmpty()) {
                throw new IllegalStateException("이미 존재하는 회원입니다."); 
            }
        }
        /**
        *전체 회원 조회
        */
        public List<Member> findMembers() {
            return memberRepository.findAll();
        }
        public Member findOne(Long memberId) {
            return memberRepository.findOne(memberId);
        }
    }

@RequiredArgsConstructor : 생성자 주입 - 변경이 불가능한 안전한 객체 생성 가능

public class MemberService {
        private final MemberRepository memberRepository;  
          // final 키워드를 추가하면 컴파일 시점에 memberRepository 를 설정하지 않는 오류를 체크할 수 있다.
        public MemberService(MemberRepository memberRepository) {
            this.memberRepository = memberRepository;
      }
          ... 
}

lombok 라이브러리가 자동완성 해주는 부분이다 !

MemberServiceTest

@RunWith(SpringRunner.class)
@SpringBootTest
@Transactional  // 테스트케이스에서 쓰일 때는, 테스트가 끝나면 강제로 롤백한다.
public class MemberServiceTest {
    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;
    @Test
    public void 회원가입() throws Exception {
        //Given
        Member member = new Member();
        member.setName("kim");

        //When
        Long saveId = memberService.join(member);

        //Then
        assertEquals(member, memberRepository.findOne(saveId));
    }
    @Test(expected = IllegalStateException.class)
    public void 중복_회원_예외() throws Exception {
        //Given
        Member member1 = new Member();
        member1.setName("kim");
        Member member2 = new Member();
        member2.setName("kim");

        //When
        memberService.join(member1);
          memberService.join(member2);  // 예외가 발생해야 한다.

        //Then
        fail("예외가 발생해야 한다.");
    }
}

애플리케이션 아키텍처

계층형 구조 사용

• controller, web : 웹 계층
• service : 비즈니스 로직, 트랜잭션 처리
• repository : JPA를 직접 사용하는 계층, 엔티티 매니저 사용
• domain : 엔티티가 모여 있는 계층, 모든 계층에서 사용

서비스, 리포지토리 계층 개발 ➡️ 테스트 케이스 작성 ➡️ 웹 계층에 적용

@OneToMany @ManyToOne @OneToOne

엔티티 클래스 개발

• Setter를 호출하면 데이터가 변하기 때문에 변경 사항을 추적하기 힘들어진다. ➡️ 실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천!
• 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다. ➡️ 엔티티나 임베디드 타입은 기본생성자를 public보다는 protected로 설정하는게 안전합니다.

*임베디드 타입은 @Embeded 나 @Embeddable으로 표현

💡 상속관계 매핑

• 1️⃣ 각각의 테이블로 변환 @Inheritance(stragy = InheritanceType.JOINED)

  ✅ 자식 테이블들을 DTYPE으로 구분하여 사용할 수 있음. ✅ 상속받는 자식 테이블을 각각 만들고, 부모 테이블의 PK를 자식 테이블의 PK이자 FK로 사용함. ➡️ 이를 통해 다른 테이블에서 부모 테이블만 보도록 설계할 수 있음.

• 2️⃣ 단일 테이블로 변환 @Inheritance(stragy = InheritanceType.SINGLE_TABLE)

  ✅ 자식 테이블들을 통합한 단일 테이블로 사용할 수 있음. ✅ @DiscriminatorValue("...") = 각각의 테이블들이 하나의 싱글테이블로 합쳐지기에 DB에서 테이블을 식별할 수 있도록 구분할 수 있는 값을 넣어줘야 함.

• 3️⃣ 서브타입 테이블로 변환 @Inheritance(stragy = InheritanceType.TABLE_PER_CLASS)

  ✅ 자식 엔티티들을 각각의 테이블로 만들어 사용함. ✅ 여러 자식들을 조회할 때, UNION을 사용하여 성능이 저하되며 다른 여러 단점들이 존재하여 자주 사용 X

💡 즉시로딩 vs 지연로딩

모든 연관관계에서 FetchType을 🔴 *지연로딩(LAZY) *🔴 으로 설정해야 한다 !!

• 즉시로딩 (FetchType - EAGER) : 엔티티를 조회할 때 연관된 엔티티를 즉시 조인해서 값을 넣어주고, 함께 조회함. ◦ 단점 : 예상하지 못한 SQL이 발생하고, 굉장히 많은 문제를 발생시킬 가능성 존재

• 지연로딩 (FetchType - LAZY) : 엔티티를 조회할 때 연관된 엔티티를 조인하지 않음. 즉 값을 넣어주지 않는다. 대신, 연관된 엔티티를 참조할 때 조인 쿼리를 작성하여 값을 넣어준다. (*필요할 때 *넣어준다는 뜻 !) ➡️ 해당 객체를 조회할 때 그 객체를 조회하는 쿼리가 발생하게 된다.

➡️ @...ToOne 의 경우, *FetchType의 디폴트가 즉시로딩으로 되어있으므로 어떤 SQL이 실행될지 추적하기 어렵기 때문에 *컬렉션은 null문제 해결을 보장하기위해 필드에서 초기화하는 것이 안전함. (@OneTo...의 디폴트는 LAZY이기에 따로 설정안해도 됨.)

💡 JPA 연관관계 매핑

데이터베이스에서 무조건 다(N)쪽이 외래 키(FK)를 갖는다 !!

• 1️⃣ 다대일 (N:1) 다(N)쪽인 엔티티에 @ManyToOne을 추가해주고, @JoinColumn("반대 쪽_id")을 추가해 반대 쪽(1)의 외래키를 갖음.

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "parent_id")
    private Category parent;

• 2️⃣ 일대다 (1:N) 일대다(단방향)는 다대일의 반대 입장이므로 같은 것이라고 생각할 수 있지만 이는 다(N)쪽이 아닌 일(1)쪽에 연관관계의 주인을 두는 방식 ! 이는 일(1)만 수정했을 때, 다(N)쪽에서도 수정이 생겨 쿼리에 문제가 생기기 때문에
• 다대일(N:1) 양방향 연관 관계를 매핑하는게 추후에 유지보수에도 수월함.*

     @OneToMany(mappedBy = "parent")
    private List<Category> child = new ArrayList<>();

• 3️⃣ 다대다 (N:M) 두 테이블 사이에 양쪽의 PK를 FK로 갖는 연결 테이블을 만들어 사용함.
• 즉, 중간 엔티티를 만들고 @ManyToOne , @OneToMany 로 매핑해서 사용하자. *

💡 영속성 전이 (JPA cascade)

CascadeType의 종류로는 ALL, PERSIST, REMOVE, MERGE, REFRESH, DETACH가 있으나 자주 사용하는 건 세 개 정도.

• ALL : 모두 적용 (PERSIST + REMOVE + ...)
• PERSIST : 영속
• REMOVE : 삭제

이는 엔티티를 영속화할 때 연관된 엔티티들도 함께 영속화해준다는 점에서 편리함을 제공하는 것이지,연관관계를 매핑하는 것과는 상관 ✖︎

ex)

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
 private List<OrderItem> orderItems = new ArrayList<>();

엔티티 설계시 주의점

💡 컬렉션은 필드에서 초기화 !

컬렉션은 필드에서 바로 초기화 하는 것이 안전하다. (선언과 초기화를 같이 하자 !)

• null 문제에서 안전하다.
• 하이버네이트는 엔티티를 영속화 할 때 컬랙션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경하기 때문에, 만약 getOrders() 처럼 임의의 메서드에서 컬력션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다.

➡️ 따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.

ex)

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
private List<OrderItem> orderItems = new ArrayList<>();

💡 테이블, 컬럼명 생성 전략

스프링 부트에서 하이버네이트 기본 매핑 전략을 변경해서 실제 테이블 필드명은 다름 !

스프링 부트 신규 설정 (엔티티(필드) ➡️ 테이블(컬럼))

• 1. 카멜 케이스 ➡️ 언더스코어(memberPoint ➡️ member_point)
• 2. .(점) ➡️ _(언더스코어)
• 3. 대문자 ➡️ 소문자

💡 Enum 타입 지정 시 주의할 점

@Enumerated(EnumType.STRING)
private DeliveryStatus status; //ENUM [READY(준비), COMP(배송)]

새로운 게 추가 되었을 때를 고려해줘야 하기 때문에, EnumType은 꼭 스트링으로 해주기 !!

application.yml

spring:
  database:
    url: jdbc:h2:tcp://localhost/~/jpashop;MVCC=TRUE  // 여러개가 한번에 접근했을 때 빨리 처리할 수 있게 도와줌.
    username: sa
    password:
    driver-class-name: org.h2.Driver

  jpa:
    hibernate:
      ddl-auto: create // 자동으로 창을 만들어줌. 어플리케이션 실행 시점에 탭을 실행함.
    properties:
      hibernate:
//        show_sql: true
        format_sql: true
logging:
  level:
    org.hibernate.SQL: debug
    rg.hibernate.type: trace // 쿼리 파라미터를 로그에 남기는 것이 가능해짐.

만약, 장고에서 하는 것처럼 request로 데이터를 받는다고 가정해보면 request에 대한 모든 프로퍼티를 작성해줘야 하기 때문에 그 번거러움을 해소하기 위해서 커맨드 객체가 존재한다.

커맨드 객체는 우리가 일반적으로 사용하는 getter/setter 메서드가 있는 VO라고 생각하면 되는데,

우리는 매개변수로 객체를 받을 수 있게 되고 객체의 생성자, 혹은 getter/setter메서드를 통해서 컨트롤러가 ObjectMapper를 통해 바인딩을 시키게 되는 것이다.

💡

강의에서 "커맨드( 명령 )와 쿼리를 구분하는 것이 좋다!" 라고 하는데, 그게 무엇이냐

• 전통적 MVC에서는 하나의 모델이 DB 조회·갱신을 모두 담당했으나,
• DB조회*를 담당하는 쿼리 모델, DB갱신을 담당하는 커맨드 모델로 역할을 분리하는 것 !

➡️ 즉, 상태조회 쿼리(query), 상태변경 명령(command) 모델로 분리하는 패턴이다.

MemberRepository

@Repository
public class MemberRepository {

    @PersistenceContext
    private EntityManager em;

    public Long save(Member member) {
        em.persist(member);
        return member.getId();    // 보통은 저장하고 나면 거의 리턴값을 만들지 않는다.
    }
    public Member find(Long id) {
        return em.find(Member.class, id);
    }
}

MemberRepositoryTest

@RunWith(SpringRunner.class)
@SpringBootTest
class MemberRepositoryTest {
    @Autowired
    MemberRepository memberRepository;

    @Test
    @Transactional  // 엔티티 매니저를 통한 모든 데이터 변경은 트랜젝션 안에서 이뤄져야 함 !!! 
    @Rollback(false)  // Test에 있는 transaction은 실행이 끝나면 바로 롤백이 되기 때문에, Test 결과를 디비에 저장하려면 Rollback(false)를 해줘야 함
    public void testMember() {
        Member member = new Member();
        member.setUsername("memberA");

        Long savedId = memberRepository.save(member);
        Member findMember = memberRepository.find(savedId);

        Assertions.assertThat(findMember.getId()).isEqualTo(member.getId());
        Assertions.assertThat(findMember.getUsername()).isEqualTo(member.getUsername());
        Assertions.assertThat(findMember).isEqualTo(member);
      // 같은 트랜잭션 안에서 저장하고 조회하면 같은 엔티티로 취급한다. => 결과는 true !
      // JPA 엔티티 동일성 보장

    }
}

• 메소드의 호출 시간을 측정하고 싶을 때 사용
• 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 분리

  @Component
  @Aspect
  public class TimeTraceAop {
        @Around("execution(* hello.hellospring..*(..))") //시간을 계산하는 위 클래스를 공통 관심 사항으로 지정
      public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
          long start = System.currentTimeMillis();
          System.out.println("START: " + joinPoint.toString());
          try {
              return joinPoint.proceed();
          } finally {
              long finish = System.currentTimeMillis();
              long timeMs = finish - start;
              System.out.println("END: " + joinPoint.toString()+ " " + timeMs +
          }
      }
   }
  

### ✅ 적용 전
![](https://velog.velcdn.com/images/gahyun_02/post/d82d3712-19d3-4ce6-87fa-ce7c50a8bb3b/image.png)
### ✅ 적용 후
![](https://velog.velcdn.com/images/gahyun_02/post/79292031-1a6a-4302-8061-17e50ef35a79/image.png)

값을 세팅하지 않고 DB에 넣으면 자동으로 generated by default as identity로 들어감

✍️ 스프링 통합 테스트

• @SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행한다.
• @Transactional : 테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다.

✍️ 스프링 JdbcTemplate

• JDBC API에서 본 반복 코드를 대부분 제거해줌.
• SQL은 직접 작성해야 한다. ✅ but ❗️ 나중에 SQL query도 작성해주는 JPA 존재.

public class JdbcTemplateMemberRepository implements MemberRepository {
    private final JdbcTemplate jdbcTemplate;
    public JdbcTemplateMemberRepository(DataSource dataSource) {
          jdbcTemplate = new JdbcTemplate(dataSource);  // 생성자가 한 개면 @Autowired 생략 가능
    }
    @Override
    public Member save(Member member) {
        SimpleJdbcInsert jdbcInsert = new SimpleJdbcInsert(jdbcTemplate);
        jdbcInsert.withTableName("member").usingGeneratedKeyColumns("id");


        Map<String, Object> parameters = new HashMap<>();
        parameters.put("name", member.getName());
        Number key = jdbcInsert.executeAndReturnKey(new MapSqlParameterSource(parameters));
        member.setId(key.longValue());
        return member;
    }

    @Override
    public Optional<Member> findById(Long id) {
        List<Member> result = jdbcTemplate.query("select * from member where id
= ?", memberRowMapper(), id);
        return result.stream().findAny();
    }

    @Override
    public List<Member> findAll() {
        return jdbcTemplate.query("select * from member", memberRowMapper());
    }

    @Override
    public Optional<Member> findByName(String name) {
        List<Member> result = jdbcTemplate.query("select * from member where
name = ?", memberRowMapper(), name);
        return result.stream().findAny();
    }

    private RowMapper<Member> memberRowMapper() {
        return (rs, rowNum) -> {
            Member member = new Member();
            member.setId(rs.getLong("id"));
            member.setName(rs.getString("name"));
            return member;
        }; 
    }
}

JPA

• SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환을 할 수 있다.
• ->* 개발 생산성을 크게 높일 수 있다.

JPA Entity Mapping

    @Entity
    public class Member {
        @Id @GeneratedValue(strategy = GenerationType.IDENTITY) // pk, identity 순
        private Long id;
        private String name;
        public Long getId() {
            return id;
        }
        public void setId(Long id) {
            this.id = id;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }

     }

JpaMemberRepository

public class JpaMemberRepository implements MemberRepository {
      private final EntityManager em;
      public JpaMemberRepository(EntityManager em) {
          this.em = em;
      }
      public Member save(Member member) {
          em.persist(member);
          return member;
      }
      public Optional<Member> findById(Long id) {
          Member member = em.find(Member.class, id);
          return Optional.ofNullable(member);
      }
      public List<Member> findAll() {
          return em.createQuery("select m from Member m", Member.class)
                  .getResultList();
      }
      public Optional<Member> findByName(String name) {

           List<Member> result = em.createQuery("select m from Member m where
  m.name = :name", Member.class)
                  .setParameter("name", name)
                  .getResultList();
          return result.stream().findAny();
      } 
}

트랜젝션

서비스 계층에 @Transactional 추가

• 해당 클래스의 메서드를 실행할 때 트랜잭션을 시작하고, 메서드가 정상 종료되면 트랜잭션을 커밋한다. (런타임 예외가 발생하면 롤백)

• JPA를 통한 모든 데이터 변경은 트랜잭션 안에서 실행해야 한다.

스프링 설정 변경할 것들

@Configuration
public class SpringConfig {

    private final DataSource dataSource;
    private final EntityManager em;
    public SpringConfig(DataSource dataSource, EntityManager em) {
        this.dataSource = dataSource;
        this.em = em;
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
        return new JdbcMemberRepository(dataSource);
        return new JdbcTemplateMemberRepository(dataSource);
        return new JpaMemberRepository(em);
    }

}

JPA 제공 기능

• 인터페이스를 통한 기본적인 CRUD
• 메서드 이름 만으로 조회 기능 제공 ( 예: findByName() )
• *페이징 *기능 자동 제공

@Controller
  public class HomeController {
      @GetMapping("/")
      public String home() {
          return "home";
      }
}

Home.html

<!DOCTYPE HTML>
  <html xmlns:th="http://www.thymeleaf.org">
  <body>
  <div class="container">
      <div>
<h1>Hello Spring</h1> <p>회원 기능</p>
<p>
<a href="/members/new">회원 가입</a> <a href="/members">회원 목록</a>
</p> </div>
   </div> <!-- /container -->
   </body>
</html>

클라이언트가 요청하는 데이터와 일치하는 것이 컨트롤러에 있는지 먼저 확인한다. (static 파일보다 우선순위가 높다.)

MemberController

@Controller
    public class MemberController {
        private final MemberService memberService;
        @Autowired
        public MemberController(MemberService memberService) {
            this.memberService = memberService;
        }

        @GetMapping(value = "/members/new")

        public String createForm() {
            return "members/createMemberForm";
        }

        @GetMapping(value = "/members")
          // 데이터를 조회할 때 씀.

          public String list(Model model) {
            List<Member> members = memberService.findMembers(); // 모든 멤버 불러오기
            model.addAttribute("members", members);
                return "members/memberList";
        }


         @PostMapping(value = "/members/new")
           // 데이터를 폼에 넣어서 전달할 때 씀.

           public String create(MemberForm form) {
           Member member = new Member();
           member.setName(form.getName());
           memberService.join(member); // join()는 정보 보내는 함수임
               return "redirect:/";
         }
         }
   }

memberList.html

<!DOCTYPE HTML>
  <html xmlns:th="http://www.thymeleaf.org">
  <body>
  <div class="container">
      <div>
          <table>
              <thead>
                               <tr>
                    <th>
                    </th>
                <th>이름</th> </tr>
              </thead>
              <tbody>
                      <tr th:each="member : ${members}">
                    <td th:text="${member.id}"></td>
                    <td th:text="${member.name}"></td>

                    <!-- th:each문에 의해 루프를 돌면서 템플릿 언어가 모델에서 members의 정보를 찾음.-->

                    </tr>
              </tbody>
            </table>
      </div>
   </div> <!-- /container -->
   </body>
   </html>

📍 스프링 빈을 등록하는 2가지 방법

• 컴포넌트 스캔과 자동 의존관계 설정
• 자바 코드로 직접 스프링 빈 등록하기

📍 컴포넌트 스캔 원리

@Service
    public class MemberService {
        private final MemberRepository memberRepository;

        @Autowired
        public MemberService(MemberRepository memberRepository) {
            this.memberRepository = memberRepository;
        }
}

• 생성자에서 @Autowired로 연결 시켜주기 (스프링 컨테이너에 의존 관계 주입시켜주는 것 = DI )

• 여러 컨트롤러 간에 공유하면서 사용가능

• @Controller @Service @Repository -> 스프링 빈으로 자동 등록됨

🔴 주의: @Autowired 를 통한 DI는 helloController , memberService 등과 같이 스프링이 관리하는 객체에서만 동작한다.

📒 자바 코드로 직접 스프링 빈 등록하기

@Configuration
public class SpringConfig {
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
   }

   @Bean
   public MemberRepository memberRepository() {
           return new MemoryMemberRepository();
   }
}

• 컨트롤러: 웹 MVC의 컨트롤러 역할

• 서비스: 핵심 비즈니스 로직 구현
• 리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리
• 도메인: 비즈니스 도메인 객체, 예) 회원, 주문, 쿠폰 등등 주로 데이터베이스에 저장하고 관리됨

• 회원 레포지토리 인터페이스 ( *인터페이스는 C++의 가상함수와 비슷 )

• • 기능별로 작성

    public interface MemberRepository {
       Member save(Member member);
       Optional<Member> findById(Long id);
       Optional<Member> findByName(String name);
       List<Member> findAll();
    }

• 회원 레포지토리 메모리 ( 구현부 )

  public class MemoryMemberRepository implements MemberRepository {
      private static Map<Long, Member> store = new HashMap<>(); // 정보를 저장하는 곳
      private static long sequence = 0L;
      @Override
      public Member save(Member member) {
          member.setId(++sequence);
          store.put(member.getId(), member);
          return member;
  }
      @Override
      public Optional<Member> findById(Long id) {
          return Optional.ofNullable(store.get(id));
      }
      @Override
      public List<Member> findAll() {
  return new ArrayList<>(store.values());
  }
      @Override
      public Optional<Member> findByName(String name) {
          return store.values().stream()
                  .filter(member -> member.getName().equals(name))
                  .findAny();
  }
      public void clearStore() {
          store.clear();
  } }

  📍 회원 레포지토리 테스트 케이스 작성

• 자바의 JUnit을 이용하여 , 속도가 빠르고 반복 실행이 가능하며 여러 테스트를 한번에 실행할 수 있다.

  class MemoryMemberRepositoryTest {
    MemoryMemberRepository repository = new MemoryMemberRepository();
    @Test
    public void save() {
        //given
        Member member = new Member();
        member.setName("spring");
  
        //when
        repository.save(member);
  
        //then
        Member result = repository.findById(member.getId()).get();
        assertThat(result).isEqualTo(member); // assertThat은 test 결과를 확인하기 위한 JUnit 중 하나
    }
  }

• given, when, then으로 나눠서 작성

• 테스트는 각각 독립적으로 실행되어야 한다. 테스트 순서에 의존관계가 있는 것은 좋은 테스트가 아니다.

** 📒 AfterEach 📒**

@AfterEach
    public void afterEach() {
        repository.clearStore();
    }

• 한번에 여러 테스트를 실행하면 메모리 DB에 직전 테스트의 결과가 남을 수 있다.
• -> @AfterEach 를 사용해서 각 테스트가 종료될 때 마다 메모리 DB에 저장된 데이터를 삭제한다.

** 📒 BeforeEach 📒 **

@BeforeEach
  public void beforeEach() {
      memberRepository = new MemoryMemberRepository();
      memberService = new MemberService(memberRepository);
  }

• 각 테스트 실행 전에 호출된다. 테스트가 서로 영향이 없도록 항상 새로운 객체를 생성하고, 의존관계도 새로 맺어준다.

📍 회원 서비스 개발

❌ 기존 방식 ❌

public class MemberService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
}

• 회원 서비스가 메모리 회원 리포지토리를 직접 생성하게 함

                        ⬇️

  public class MemberService {
      private final MemberRepository memberRepository;
      public MemberService(MemberRepository memberRepository) {
          this.memberRepository = memberRepository;
  }
  ...
  }

• MemberService 입장에서, 외부에서 memberRepository를 넣어줄 수 있도록 (=DI 가능하게 ) 변경

📍 회원 서비스 테스트

class MemberServiceTest {
    MemberService memberService;
    MemoryMemberRepository memberRepository;

    @BeforeEach
    public void beforeEach() {
        memberRepository = new MemoryMemberRepository();
        memberService = new MemberService(memberRepository);
    }

    // MemoryMemberRepository와 MemberService는 서로 다른 리포지토리인데 같은 메모리를 사용하게 하기 위한 코드

    @AfterEach
    public void afterEach() {
        memberRepository.clearStore();
    }

    // 테스트 주도 개발에서 함수 이름은 한글로 많이 씀.
    @Test
    public void 중복_회원_예외() throws Exception {
        //Given
        Member member1 = new Member();
        member1.setName("spring");
        Member member2 = new Member();
        member2.setName("spring");

         //When
        memberService.join(member1);
        IllegalStateException e = assertThrows(IllegalStateException.class,
            () -> memberService.join(member2)); 
            // 예외가 발생해야 한다. 
            // assertThrows는 Try-catch 대신에 예외 처리하려고 쓰는 것임.

        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
    }
}