1. sizeof()

• 자료형의 byte 크기를 나타냄

  #include <stdio.h>
  

int main() { int num1 = 0; int size;

size = sizeof num1;    // 변수 num1의 자료형 크기를 구함

printf("num1의 크기: %d\n", size);

return 0;

}

// 출력 // num1의 크기: 4

## 2. switch case 문
```C
#define _CRT_SECURE_NO_WARNINGS    // scanf 보안 경고로 인한 컴파일 에러 방지
#include <stdio.h>

int main()
{
    int num1;

    scanf("%d", &num1);    // 값을 입력받음

    // switch의 case에서 break 삭제
    switch (num1)
    {
    case 1:    // 1일 때는 아래 case 2, default가 모두 실행됨
        printf("1입니다.\n");
    case 2:    // 2일 때는 아래 default까지 실행됨
        printf("2입니다.\n");
    default:
        printf("default\n");
    }

    return 0;
}

• switch 문의 case에 break가 없다면, 밑의 case문들과 deafult까지 출력하게 된다. (fall through)

isdigit()

숫자인지 아닌지 판단하는 함수

#include <stdio.h>
#include <ctype.h>

int main()
{
    char arr[13] = "ABCDEF123456";
    printf("arr : %s \n\n", arr);

    for (int i = 0; i < 12; i++)
    {
        printf("arr[%d] = %c    isdigit: %d \n",i,arr[i], isdigit(arr[i]));
    }
    return 0;
}

포인터

Java

1. extends -> 상속

ex)

class SuperObject {
    public void paint(){
        draw();
    }

    public void draw(){
        draw();
        System.out.println("Super Object");
    }
}


class SubObject extends SuperObject {
    public void paint(){
        super.draw();
    }

    public void draw(){
        System.out.println("Sub Object");
    }
}


public class Test{
    public static void main(String[] args){
        SuperObject a = new SubObject();
        a.paint();
    } 
}

클래스 SubObject를 정의하고 부모 클래스로 SuperObject를 지정하면 SuperObject에 속한 변수와 메서드를 상속받습니다.

자식 클래스 생성자로 인스턴스를 생성할 때 자료형을 부모 클래스로 지정하면 생성된 인스턴스는 부모 클래스로 묵시적 클래스 형 변환이 됩니다. 부모와 자식 클래스간 같은 메서드가 존재하면 호출되는 메서드는 생성된 인스턴스에 따라 결정됩니다.

a.paint()는 클래스 형 변환을 수행하였고 print()메서드가 자식 클래스에서 재정의를 통해 오버라이딩 된 메서드이므로 자식 클래스의 paint 메서드가 수행됩니다.

부모 클래스를 호출하는 super를 사용했으므로 부모 클래스의 draw() 메서드를 수행합니다.

부모 클래스 draw()에서 처음에 클래스 형 변환을 수행하였고 draw()메서드가 자식 클래스에서 재정의를 통해 오버라이딩 된 메서드이므로 자식 클래스의 draw()메서드를 수행합니다.

자식 메서드 draw를 수행하면서 'Sub Object가 수행되고' 다시 부모 draw()로 돌아가 나머지 'Super Object'를 수행합니다.

• 부모클래스 변수명 = New 자식생성자
  • ```java SuperObject a = new SubObject();
  • 부모 클래스 객체 생성. but, 자식객체의 생성자 사용
    • 부모 클래스와 자식 클래스에 동일한 속성이나 메소드가 있다면, 자식 클래스로 재정의

2. == 와 .equals()

• == 은 객체의 참조(주소)를 비교한다.
• .equals()는 말그대로 해당 참조에 있는 데이터를 비교함

public class Main {
    public static void main(String[] args) {
        String str1 = "Programming";
        String str2 = "Programming";
        String str3 = new String("Programming");

        System.out.println(str1 == str2);      // ①
        System.out.println(str1 == str3);      // ②
        System.out.println(str1.equals(str3)); // ③
        System.out.print(str2.equals(str3));   // ④
    }
}

//결과
true
false
true
true

1️⃣ String str1 = "Programming";

문자열 리터럴 "Programming"을 String Constant Pool(문자열 상수 풀)에 저장. str1이 "Programming"을 가리킴.

2️⃣ String str2 = "Programming";

동일한 문자열 "Programming"이 이미 String Pool에 존재. str2는 str1과 동일한 "Programming"을 참조.

3️⃣ String str3 = new String("Programming");

new String("Programming")은 Heap 영역에 새로운 문자열 객체를 생성. str3은 String Pool의 "Programming"을 참조하지 않고, 새로 생성된 객체를 참조

해설 따라서 str1, str2는 동일한 Programming을 참조 하지만, 생성자를 통한 str3은 힙영역에 저장되기 때문에 str1, str2와 다른 주소를 갖고 있다.

Python

리스트와 세트

리스트 생성 방법

a = ['a', 'b', 'c']

세트 생성 방법

a = {'a', 'b', 'c'}

리스트

• 순서가 있음
• 중복된 데이터가 있을 수 있음
• 여러 자료형을 저장할 수 있음 ex) a = [3, 1.234, 'ABC']
• 선언 시, 크기를 적지 않아도 됨

세트

• 순서가 정해져있지 않음
• 중복된 데이터는 저장되지 않음

리스트 관련 주요 메서드

• apppend(값)
  • 리스트에 값을 추가한다.

Ex)

[1, 2, 3].append(4) -> [1, 2, 3, 4]

• pop(위치)
  • 리스트의 '위치'에 있는 값을 출력하고 해당 요소를 삭제한다.

ex)

[10, 11, 12].pop(1) -> 11 출력 -> [10, 12]

• index(값)
  • 리스트에서 '값'이 저장된 요소의 위치를 반환한다.

ex)

[10, 11, 12].index(2) -> 2

• count(값)
  • 리스트에서 '값'이 저장되어 있는 요소들의 개수를 반환한다.

ex)

[1, 0, 1, 1, 0].count(1) -> 3

• extend(리스트)
  • 리스트의 끝에 새로운 리스트를 추가하여 확장한다.

ex)

['a', 'b'].extend(['c', 'd']) -> ['a', 'b', 'c', 'd']

• reverse()
  • 리스트의 순서를 역순으로 뒤집는다.

ex)

[10, 11, 12].reverse() -> [12, 11, 10]

• sort()
  • 리스트를 정렬하며, 기본값은 오름차순이다.

ex)

   [2, 1, 3].sort() -> [1, 2, 3] 

   [2, 1, 3].sort(reverse = True) -> [3, 2, 1]

• copy()
  • 리스트를 복사한다.

ex)

a = [1,2,3]
b = a.copy()

세트 관련 주요 메서드

• pop()
  • 세트의 값을 출력하고 요소를 삭제한다.

ex)

{10, 11, 12}.pop() -> 10 출력 -> {11, 12}

• add(값)
  • 세트에 값을 추가한다.

ex)

{10, 11, 12}.add(13) -> {10, 11, 12, 13}

• update(세트)
  • 세트에 새로운 '세트'를 추가하여 확장한다.

ex)

{'a', 'b', 'c'}.update({'c', 'd'}) -> {'a', 'b', 'c', 'd'}

• remove(값)
  • 세트에서 '값'을 찾아 해당 요소를 삭제한다.

ex)

{10, 11, 12}.remove(11) -> {10, 12}

튜플

튜플 생성 방법

tuple1 = (1, 'b', 'c')
tuple2 = tuple(['a', 'b']) 

튜플

• 순서가 있음
• 중복된 데이터가 있을 수 있음
• 여러 자료형을 저장할 수 있음
• 리스트와는 다르게 수정 및 삭제 불가능
• 값이 한개만 들어갈 경우 값을 넣고 콤마(,)를 넣어줘야 함.

ex)

tuple = (1,)

Range

• Range는 연속된 숫자를 생성하는 것으로, 리스트나 반복문에서 많이 사용된다.

<형식>

range(최종값)

• 0에서 최종값 - 1까지 연속된 숫자를 생성한다.

range(초기값, 최종값)

• 초기값에서 최종값 - 1까지 연속된 숫자를 생성한다.

range(초기값, 최종값, 증가값)

• 초기값에서 최종값 - 1까지 증가값만큼 증가하면서 숫자를 생성한다.
• 증가값이 음수인 경우 초기값에서 최종값 + 1까지 증가값 만큼 감소하면서 숫자를 생성한다.

Slice

• Slice는 문자열이나 리스트와 같은 순차형 객체에서 일부를 잘라 반환하는 기능이다.

객체명[초기위치:최종위치]

• 초기위치에서 최종위치 - 1까지의 요소들을 가져온다.

객체명[초기위치:최종위치:증가값]

• 초기위치에서 최종위치 - 1까지 증가값 만큼 증가하면서 해당 위치의 요소들을 가져온다.
• 증가값이 음수인 경우 초기위치에서 최종위치 + 1까지 증가값만큼 감소하면서 해당 위치의 요소들을 가져온다.

객체명[:] 또는 객체명[::]

• 객체의 모든 요소를 반환한다.

객체명[초기위치:]

• 객체의 초기위치에서 마지막 위치까지의 요소들을 반환한다.

객체명[:최종위치]

• 객체의 0번째 위치에서 최종위치 - 1까지의 요소들을 반환한다.

객체명[::증가값]

• 객체의 0번째 위치에서 마지막 위치까지 증가값만큼 증가하면서 해당 위치의 요소들을 반환한다.

대문자 변환(upper, capitalize..)

• upper() : 모든알파벳을 대문자로 변환
• capitalize() : 맨 첫글자만 대문자로 변환
• title() : 알파벳 외의 문자(숫자, 특수기호, 띄어쓰기 등)로 나누어져 있는 영단어들의 첫 글자를 모두 대문자로

A='abcd'
print(A.upper()) #ABCD
print(A.capitalize()) #Abcd
print(A.title()) #Abcd

B='a2b3c4'
print(B.upper()) #A2B3C4
print(B.capitalize()) #A2b3c4
print(B.title()) #A2B3C4

C="abc-def efg"
print(C.upper()) #ABC-DEF EFG
print(C.capitalize()) #Abc-def efg
print(C.title()) #Abc-Def Efg

find()

• string.find(찾을 문자)

  str = "findletter"
  print(str.find("d"))
  #
  #결과
  3 

• string.find(찾을 문자, 시작 Index)
• string.find(찾을 문자, 시작 Index, 끝 Index)

find 함수 첫번째 인자- 찾을 문자열 혹은 찾을 문자

find 함수 두번째 인자 (생략가능)- 문자를 찾을때 어디서 부터 찾을지 시작 index. 생략시 0

find 함수 세번째인자 (생략가능)- 문자를 찾을때 어디 까지 찾을지 끝 index, 생략시 문자열 맨 마지막 index

만약 찾는 단어가 없다면 -1 출력

str = "findletter"
print(str.find("s"))
#
#결과
-1

중복된 단어가 있다면 가장 첫번째 인덱스를 출력

str = "findletter"
print(str.find("t"))
#
#결과
6 # 7 인덱스에도 t가 있으나 6만 확인 가능

in

• 문자열 내에 찾고자 하는 문자열이 있는지 여부를 boolean값으로 반환

str = "findletter"
print("d" in str)
print("s" in str)
#
#결과
True
False

아스키코드

'A' = 65 'a' = 97

16진수 변환

0 1 2 3 4 5 6 7 8 9 A = 10 B = 11 C = 12 D = 13 E = 14 F = 15

알아두기 혹시 모르니

• 자바의 힙 공간은 객체와 JRE 클래스들에게 메모리를 할당할 때 사용 된다.
• 객체가 생성되면 힙 공간에 할당되며, 이 객체에 대한 참조가 스택 메모리에 저장된다.
• 가비지컬렉션은 힙 메모리에 더이상 참조하지 않는 객체들을 정리 한다.
• 힙에 만들어진 객체는 어디서든 접근할 수 있고, 어플리케이션 어디에서나 참조될 수 있다.

Heap 특징

• 힙 영역이 가득차면 OutOfMemoryError가 발생
• 스택 영역에 비해 엑세스 속도가 조금 느리다.
• 스택 영역과 달리 메모리 해제가 자동으로 되지 않는다.
• 메모리 사용의 효율성을 위해 GC가 필요하다.(Garbage Collection)
• Thread-safe하지 않기 때문에 적절히 synchronizing을 해야한다.

Stack

• 정적 메모리 할당 및 쓰레드 실행을 위해 사용되는 영역
• 메소드에 고유한 기본 값과 메소드에서 참조하는 힘 개체에 대한 참조값을 포함하고 있다.
• LIFO(Last-In-First-Out) 순서로 동작된다.
• 새 메소드가 호출될 때마다 스택 상단에 해당 메소드에 대한 새블록이 생성된다.
• 메소드 실행이 완료되면 해당 스택에서 pop되고, 호출한 메소드로 흐름이 돌아가게 된다.

Stack 특징

• 스택 내부의 변수는 변수를 생성한 메소드가 실행되는 동안만 존대한다.
• 메소드 실행에 따라 자동으로 할당되고 해제된다.
• 해당 메모리 영역이 가득차면 StackOverFlowError가 발생.
• 힙 메모리에 비해 엑세스 속도가 빠르다.
• 쓰레드마다 고유의 스택 영역을 가지고 있으므로, Threa-safe하다.

Heap과 Stack 차이점

• 힙 메모리는 어플리케이션의 모든 부분에서 사용된다.
• 스택 메모리는 하나의 쓰레드가 실행 될 때 사용된다.
• 객체가 생성되면 항상 힙 공간에 저장된다.
• 스택 메모리는 힙 공간에 있는 객체를 참조만 한다.
• 스택 메모리는 primitive 타입의 지역변수와 힙 공간에 있는 객체 참조 변수만 갖고 있다.
• 힙 공간에 저장된 객체는 어디서든 접근이 가능하다.
• 스택 메모리는 다른 쓰레드가 접간할 수 없다. (Heap보다 어느정도 보안성이 있다.)
• 스택 메모리의 생명주기는 매우 짧다.
• 힙 메모리는 어플리케이션의 시작부터 끝까지 남아있다.
• 스택 메모리가 가득차면 java.lang.StackOverFlowError 발생
• 힙 메모리가 가득차면 java.lang.OutOfMemoryError 발생
• 스택 메모리의 사이즈는 힙 메모리와 비교시 매우 적다.

이번 회고록은 나의 배포 준비단계를 작성해보려고 한다.

가장 먼저 나는 docker를 이용하여 aws에 올릴 생각이었다.

docker에 나의 이미지를 올리고 aws인스턴스에 docker를 다운받아 해당 서버를 올릴 생각이었다.

그래서 3일간 열심히 찾아보고 도전해보았다.

docker-compose 파일을 이용하여 내 프로젝트와 db를 연결하려고 했지만, 자꾸만 오류를 나타내었다.

그래서 결국 aws만을 사용해서 배포하기로 결정하였다.

하지만, 여러 걸림돌이 걸렸었다.

프리티어

아직 돈을 벌지 못하는 일개 대학생으로써 프리티어 버전으로 인스턴스를 만들고, 해당 인스턴스에 내 프로젝트파일을 옮기고 jar파일을 만드려하는데, 10분이 지나도 완료가 도저히 안되었다.

그래서 구글링 결과.

프리티어 버전의 인스턴스는 RAM이 1기가 밖에 안되기 때문에 파일이 크면 오래 걸리기도 안되기도 한다고 한다.

그래서 swap 파일을 사용하여 RAM 용량을 늘려 build하였다.

이전보다 금방 되는 모습을 확인할 수 있었다.

DB

자꾸 서버에서 패킷을 못받았다는 오류를 받았다.

아직 무지한 상태인 나이기에 부끄럽지만 적어본다.

사실 나는 원래 aws 서버에 내 프로젝트를 올리고, 내 컴퓨터에 있는 mysql db를 사용하려 했다.

그러나 계속 jar 파일을 실행해도, db쪽에서 에러가 났다.

그래서 aws의 rds를 사용하여 내 프로젝트에 해당 db를 연결한 후 서버를 실행하니 정상적으로 잘 작동 되었다.

내 로컬 pc에 있는 db를 사용해서 서버를 배포하는게 되는지 안되는지 사실 잘 모르겠다.

이것도 나중에 공부를 해볼 것이다.

결국 이 프로젝트의 마무리를 지었다.

배포 과정과 마무리 회고록은 나중에 쓰도록 하겠다.

나머지 자잘자잘한 것들은 간단하여 생략하였다.

주요기능

1. 로그인시 nav바 변경

2. nav바 프로필 사진 변경

3. 주소 설정 select box

로그인 시 nav바 변경

사실 이 프로젝트를 하기 전에 하다가 중단된 프로젝트가 있었다.

나를 포함한 팀원들 모두 아무것도 모르는 상태에서 하려다 중단되었었는데,

그 프로젝트에서도 로그인 했을 때 nav바를 변경하는 방법을 몰랐다.

그래서 이번 프로젝트에서도 이 부분이 가장 해결하기 어렵다 생각했던 부분 중 하나이다.

하지만, 지금의 나는 session공부를 함으로써 어떤 방식으로 nav바를 변경해야 하는지 알게 되었고, 정말 간단한 방법으로 nav바를 변경할 수 있었다.

만약 로그인을 했다면, 서버에서 해당 사용자의 session을 생성했다.

이 session을 사용하여 nav바를 변경하였다.

가장 먼저 로그인 했을 때의 nav바 파일과 로그인이 안됐을 때의 nav바 파일을 따로 생성한 후 타임리프를 이용하여 nav바를 교체하는 방식으로 진행하였다.

    if(userIndex != null){
            Optional<ProfileEntity> userProfile = profileService.findProfileEntity(userIndex);
            // session이 있을 때 true 반환해 login된 header사용
            model.addAttribute("alreadyHaveSession", "true");
            if(userProfile.isPresent()){
                model.addAttribute("storeFileName", userProfile.get().getStoreFileName());
            }
        }
        else if(userIndex == null){
            // session 없을 때 false반환해 기본 header사용
            model.addAttribute("alreadyHaveSession", "false");
        }
    }

위의 코드는 메인 페이지 메서드중 하나이다.

위의 코드처럼 유저 index가 있을 때 alreadyHaveSession이라는 모델을 가져오도록 한다.

<div th:if="${alreadyHaveSession == 'true'}">
        <div th:replace="newHeader.html"></div>
      </div>
      <div th:if="${alreadyHaveSession == 'false'}">
        <div th:replace="existingHeader.html"></div>
      </div>

만약 alreadyHaveSession이 true이면, 해당 사용자가 로그인을 했을 상태이기 때문에, 로그인이 된 nav바를 대체하도록 하고 false이면 로그인이 안된 상태의 nav바를 반환하도록 하였다.

nav바 프로필 사진 변경

이 부분은 로그인한 유저의 프로필 사진이 변경되었을 때, 프로필 사진을 가져와 nav바에 사진을 걸어 두는 것이다.

위의 코드에서 보듯 storeFileName이라는 모델로 해당 사용자의 프로필 사진을 가져온다.

        <img
          class="picture"
          onerror="this.src='/img/default_profile.png'"
          th:src="@{/upload/{uploadfile}(uploadfile=${storeFileName})}"
        />

타임리프를 사용하여 해당 사진의 주소를 받아와 보여준다.

가장 처음 회원가입을 했을 때에는 프로필 사진이 없기 때문에 만약 해당 프로필 사진이 없으면 기본 프로필 사진을 받아 올 수 있도록 onerror 속성을 사용하여 기본 프로필 사진을 가져오도록 하였다.

주소 설정 select box

이 부분이 이 프로젝트에 있어서 가장 어려웠고 시간을 가장 많이 쓴 문제였다.

우선 나는 프론트엔드 개발자가 아니다. js를 잘 모르는 상태로 시도해서 시간을 많이 쓴 것 같기도 하다.

그냥 어느정도 어떤 식으로 js가 돌아가는지만 아는 그런 수준인 상태였다.

나는 당근마켓 웹페이지의 주소 select와 비슷하게 만들고 싶었다.

가장 중요한 부분은 해당 구/군을 선택하면 해당 구/군에 있는 동들이 나와야 한다.

그리고 해당 시 / 군 / 구 를 선택할 때 해당 지역을 선택한 게시글들이 나오게 만드는 것이다.

예를 들면, 경기도 용인시 수지구까지만 선택했다면, 경기도 용인시 수지구를 선택했던 게시글들만 나오게 하는 것이다.

우선 이 select box의 option 값들이 너무 많아 프로토타입으로 서울특별시의 지역만 option값으로 넣어두었다.

여러가지 시도를 해보았다.

option값을 selected 속성을 사용하여 만들어, js로 url주소를 만들어 이동하는 방식으로도 해보았지만, 페이지가 넘어가면서 해당 주소를 selected한 option값을 못 받아 왔다.

이런 여러가지 방식으로 시도해왔지만, 번번히 실패했다.

결국 오랜 구글링 끝에 sessionStorage를 사용하여 해당 selected값을 가져오는 방식으로 도전해보았다.

이 방법은 이전에 같이 프로젝트를 해온 프론트엔드 팀원이 해보다 실패했다고 회의하면서 들었어서, 반신반의하며 도전하였다.

방식은 이렇다.

select box에서 해당 지역을 클릭하면 해당 option의 value 값을 받아와 sessionStorage에 저장한 후 새로운 페이지에서 해당 지역의 게시글을 받아오고, selected 한 지역은 sessionStorage에서 받아와 select box에 넣어주는 방식이다.

이전에 프론트를 담당한 팀원이 select box를 해놓았는데 그걸 이용하여 코드를 진행해보았다.

원래는 다음페이지까지 이동은 했지만, selected가 되지않아 다음 지역 selectbox가 선택되지 않았다.

팀원이 짠 코드를 console.log를 찍어가며 어떤 식으로 코드진행이 되는지를 알아가며 차근차근 천천히 풀어나가니 결국에 내가 원하는 기능을 제대로 실행할 수 있게 되었다.

주요 기능

1. 프로필 수정

2. 회원 탈퇴 및 비밀번호 변경

1. 프로필 수정

사실 이 부분은 js작업 보다 서버쪽 코드 수정이 주였다.

사실 프로필 수정 자체는 form 태그의 multipart타입으로 만들면 쉽게 만들어진다.

말그대로 프로필 사진과 이름, 닉네임, 전화번호도 쉽게 수정되었다.

한가지 문제점을 내가 놓친 것이 있었는데, 만약 사용자가 게시글을 하나 이상 작성했거나, 댓글을 쓴 경우가 있는 상태에서 프로필을 바꾸면 해당 게시글과 댓글 프로필사진 및 닉네임도 변경이되어야 하는데, 그 부분을 생각하지 못했다.

게시글, 댓글, 사용자 닉네임 수정

    public Optional<UserEntity> changeUserInfo(Long userIndex, UserEntity userInfo) {
        Optional<UserEntity> user = userRepository.findById(userIndex);

        List<PostEntity> userPost = postRepository.findByUserIndex(userIndex);
        List<ReplyEntity> userReply = replyRepository.findByReplyUserIndex(userIndex);

        for(PostEntity post : userPost){
            post.setUserNickName(userInfo.getUserNickName());

            postRepository.save(post);
        }

        for(ReplyEntity reply : userReply){
            reply.setUserNickName(userInfo.getUserNickName());

            replyRepository.save(reply);
        }

        return user.map(p -> {
            user.get().setUserName(userInfo.getUserName());
            user.get().setUserNickName(userInfo.getUserNickName());
            user.get().setUserPhoneNumber(userInfo.getUserPhoneNumber());

            return p;
        })
        .map(p -> userRepository.save(p));

    }

나는 user 엔티티와 프로필 엔티티를 따로 두어 userIndex를 통해 새로운 프로필을 만들거나 수정하는 방식으로 만들었다. 그래서 위 코드에는 프로필 사진 수정에 대한 코드는 없다.(아래에서 설명할 것이다.)

return user.map(p -> { user.get().setUserName(userInfo.getUserName()); user.get().setUserNickName(userInfo.getUserNickName()); user.get().setUserPhoneNumber(userInfo.getUserPhoneNumber()); return p; }) .map(p -> userRepository.save(p));

가장먼저 바뀐 사용자 정보를 원래 가지고 있던 유저 정보에서 수정한다.

List<PostEntity> userPost = postRepository.findByUserIndex(userIndex); List<ReplyEntity> userReply = replyRepository.findByReplyUserIndex(userIndex);

해당 코드는 사용자가 쓴 댓글과 게시글 전체를 가져오는 것이다.

그 다음 각각의 게시글과 댓글의 닉네임을 수정하여 저장한다.

게시글, 댓글 프로필 사진 수정

    public Optional<ProfileEntity> saveProfile(MultipartFile originFileName, Long userIndex) throws IOException {
        Optional<ProfileEntity> storeFile = fileStore.storeFile(originFileName, userIndex);

        List<PostEntity> userPost = postRepository.findByUserIndex(userIndex);
        List<ReplyEntity> userReply = replyRepository.findByReplyUserIndex(userIndex);

        for(PostEntity post : userPost){
            post.setStoreFileName(storeFile.get().getStoreFileName());

            postRepository.save(post);
        }

        for(ReplyEntity reply : userReply){
            reply.setStoreFileName(storeFile.get().getStoreFileName());

            replyRepository.save(reply);
        }
        return storeFile;
    }

만약 사용자가 프로필 사진을 바꾼다면 실행되는 메서드이다.

Optional<ProfileEntity> storeFile = fileStore.storeFile(originFileName, userIndex);

가장 먼저 사용자의 프로필 사진을 저장한다.

이후 위의 게시글, 댓글의 닉네임을 변경하듯이, 프로필 사진을 각각의 게시글과 댓글에 수정하여 저장시킨다.

문제점

사실 이 방법이 맞는건지 잘 모르겠다.

내가 생각한 문제점은 데이터베이스적인 문제인것 같다.

사실 나의 무지함에서 일어난 문제같다.

사용자와 댓글, 게시글은 일대다 연관관계로, jpa를 사용한다면, getUserProfile() 이런식으로 게시글에서 사용자 프로필을가져올 수 있을 것이다.

하지만, 나는 닉네임과 프로필 사진을 게시글과 댓글에 새로운 컬럼으로 넣어두었고, 그렇게 해서 타임리프를 통해 뷰단에 뿌릴수 있다고 생각했다.

만약 게시글과 댓글에 사용자의 index만 가지고 뷰단에 뿌리게 된다면, 타임리프를 통해 어떤 방식으로 사용자의 닉네임과 프로필 사진을 가져오는 방법을 모르기 때문에 위의 방식으로 프로젝트를 진행하였다.

이게 맞는 것인지 틀린 것인지도 잘 모르겠다.

우선 배포과정까지 마무리한 후 다시 한번 손봐야 할 것 같다.

회원 탈퇴 및 비밀번호 변경

해당 로직은 아주 쉽게 끝났다.

$("#withdrawBtn").click(() => {
    const confirmed = confirm("회원탈퇴를 하시겠습니까?");

    if (confirmed) {
      $.ajax({
        url: "/user/delete",
        type: "DELETE",
        success: function () {
          alert("회원탈퇴가 완료되었습니다.");

          window.location.href = "/";
        },
      });
    }
    // alert에서 취소 누르면 원상복귀
  });

말 그대로 회원 탈퇴 방법을 ajax를 사용하여 회원탈퇴 버튼을 누르면 탈퇴를 할것인지 alert를 띄우고, 취소를 누르면 취소가 되고, 확인 버튼을 누르면 회원탈퇴가 되도록 만들었다.

비밀번호 변경도 쉽게 만들었다.

$("#submitBtn").click(() => {
    const newPassword = $("#inputNewpw").val();

    // 비밀번호 변경 input 이 비어있을 경우
    if (newPassword.trim() === "") {
      alert("변경사항이 없습니다.");
      return;
    }

    // 새로운 비밀번호를 입력한 경우
    const confirmed = confirm("비밀번호를 변경하시겠습니까?");

    if (confirmed) {
      $.ajax({
        url: "/change/pw",
        type: "POST",
        data: { newPassword: newPassword },

        success: function (response) {
          alert("비밀번호를 변경하였습니다!");
        },
        error: function (xhr, status, error) {
          alert("에러가 발생했습니다.");
        },
      });
      // alert에서 취소 누르면 원상복귀
    }
  });

게시글 쓰는 페이지는 다른 팀원이 하기로 하고 나는 메인페이지에서 게시글을 클릭했을 때 나오는 게시글 상세화면을 만들었다.

주요 기능

1. 해당 게시글이 자신이 쓴 게시글이라면 게시글 수정 및 삭제 버튼 활성화

2. 해당 게시글 thymeleaf 작업

3. 해당 게시글의 댓글 thymeleaf 작업

1. 해당 게시글이 자신이 쓴 게시글이라면 수정 및 삭제 버튼 활성화

이 부분이 사실 게시글 상세화면 부분에서 가장 어려운 부분이라고 생각한다.

우선 게시글 상세화면은 로그인세션이 있는 상태, 로그인이 되어있지 않은 상태 둘다 해당 페이지를 들어올 수 있기 때문에 게시글 수정 및 삭제 버튼은 게시글의 주인이 로그인하지 않는이상 활성화 되면 안된다.

이 부분을 어떻게 하면 좋을까 곰곰히 생각해보았다.

해당 게시글의 index와 로그인된 유저의 index가 같으면 해당 버튼들이 활성화 되어야 한다.

그래서 게시글을 가져올때의 메서드에 thymeleaf값 하나를 가져와서 만들기로 생각했다.(나중에 좋은 방법이 생각났다.)

@GetMapping("/post/{postId}")
    public String read(HttpSession session, @PathVariable(name = "postId") Long postId, Model model) {
        Long userIndex = (Long) session.getAttribute("userIndex");
        model.addAttribute("userIndex", userIndex);

        // 게시글 model
        Optional<PostEntity> post = postService.read(postId);
        post.ifPresent(o -> model.addAttribute("post", o));

        // 세션을 가져와서 만약 게시글, 댓글 userIndex와 같다면
        // 1을 출력해 수정 및 삭제 버튼 활성화 
        // 로그인 했지만, 다르면 0 
        // 로그인하지 않았다면, 2 출력
        // 수정 필요
        Integer checkedUserIndexForPost = 0;
        if(userIndex != null){
            if(userIndex == post.get().getUserIndex()){
                // 게시글, 댓글, 세션이 같으면
                checkedUserIndexForPost = 1;
                model.addAttribute("checkIndexForPost", checkedUserIndexForPost);
            } else if(userIndex != post.get().getUserIndex()){
                checkedUserIndexForPost = 2;
                model.addAttribute("checkIndexForPost", checkedUserIndexForPost);
            }
        }
        else if(userIndex == null){
            model.addAttribute("checkIndexForPost", checkedUserIndexForPost);
        }

        return "post_detail";
    }

가장 먼저 해당 게시글을 가져와 model화 해준다.

그 후 userIndex가 있을 때 없을 때를 비교하고 없다면 2, 로그인하여 userIndex가 있지만, 게시글 index와 다르다면 0, 해당 게시글이 로그인한 사용자의 게시글이면 1을 반환하여 model에 넣어주었다.

이 값을 js에서 받아서 확인하는 방식으로 진행하였다.

$(document).ready(() => {
  var index_button = $("input[name=index_button]").val();
  if (index_button == 1) {
    console.log(index_button);
    $(".deleteEdit").css("display", "flex");
  }
});

$("input[name=index_button]").val();

이 부분은 해당 타임리프 값을 input hidden 값으로 html에 집어넣어 해당 value를 가져오게 만든 것이다.

<input type="hidden" name="index_button" th:value="${checkIndexForPost}"/>

개선사항

사실 어짜피 로그인세션의 userIndex를 model화 한다면, 위의 방법보다, userIndex의 value값을 가져오고, thymeleaf로 가져온 게시글 model에서 userIndex를 뽑아와 그 둘을 비교시켜도 되었을 것이다.

그것이 유지보수에 좀 더 도움이 되었을 것이다.

나중에 해당 프로젝트를 리펙토링하게 된다면 이 부분을 고쳐주고 싶다.

2. 해당 게시글 thymeleaf 작업

해당 thymeleaf 작업은 너무 쉬워서 넘어가겠다.

3. 해당 게시글의 댓글 js, thymeleaf 작업

댓글 작성은 form 태그를 이용하여 구현하였다.

여기서 댓글을 작성한 후 해당 댓글을 보게 되면 만약 로그인한 유저가 해당 댓글을 썼다면, 수정 및 삭제 버튼이 생긴다.

이 부분을 위에 게시글 수정 삭제 버튼의 개선사항으로 만들어 보았다.

thymeleaf의 th:style을 이용하여 만약 같다면 해당 display를 활성화 시키는 방법으로 만들었다.

<div
  class="deleteEditC"
  th:style="${reply.replyUserIndex == userIndex ? 'display:flex' : 'display:none'}"
>
    <button class="editC">수정</button>
    <form
         th:action="@{/reply/delete/{replyIndex}(replyIndex=${reply.replyIndex})}"
         method="post"
    >
    <input type="hidden" name="_method" value="delete" />
    <button class="deleteC">삭제</button>
    </form>
</div>

각각의 댓글의 userIndex를 가져와 만약 로그인세션의 userIndex와 같다면 해당 버튼들을 활성화 하고 다르면 비활성화 하게 만들었다.

댓글 수정은 ajax를 이용하여 비동기 방식으로 구현하였다.

document.addEventListener("DOMContentLoaded", function () {
  // Addeventlisteners "수정" 버튼
  function handleEditClick(event) {
    const commentBox = event.target.closest(".commentBox");
    const commentText = commentBox.querySelector(".comment");
    const commentContent = commentText.innerText;

    const textarea = document.createElement("textarea");
    textarea.classList.add("editTextarea");
    textarea.name = "editedComment";
    textarea.value = commentContent;

    const saveButton = document.createElement("button");
    saveButton.classList.add("saveC");
    saveButton.innerText = "저장";

    const editDeleteContainer = commentBox.querySelector(".deleteEditC");
    editDeleteContainer.innerHTML = "";
    commentText.innerHTML = "";
    commentText.appendChild(textarea);
    editDeleteContainer.appendChild(saveButton);

    //기능 삭제
    event.target.removeEventListener("click", handleEditClick);

    saveButton.addEventListener("click", function () {
      const editedComment = textarea.value;
      var reply_index = $("input[name=reply_index]").val();

      $.ajax({
        url: "/reply/edit/" + reply_index,
        type: "POST",
        data: {
          replyDescription: editedComment,
        },
        success: function (response) {
          console.log("업데이트에 성공했습니다.");

          commentText.innerText = editedComment;
          editDeleteContainer.innerHTML = "";

          const editButton = document.createElement("button");
          editButton.classList.add("editC");
          editButton.innerText = "수정";

          const deleteButton = document.createElement("button");
          deleteButton.classList.add("deleteC");
          deleteButton.innerText = "삭제";

          editDeleteContainer.appendChild(editButton);
          editDeleteContainer.appendChild(deleteButton);

          //다시 적용
          editButton.addEventListener("click", handleEditClick);
        },
      });
    });
  }

  const editButtons = document.querySelectorAll(".editC");
  editButtons.forEach((button) => {
    button.addEventListener("click", handleEditClick);
  });
});

수정 버튼을 눌렀을 때, handleEditClick함수가 실행되어 textarea와 저장 버튼을 추가 시킨뒤 저장 버튼을 눌렀을 때 ajax로 수정이 가능하게 만들었다.

삭제 버튼은 form 태그를 이용하여 바로 삭제 가능하게 구현하였다.

그래서 가장 첫번째로 건든 부분이 회원가입/로그인 부분이다.

signup.html

회원 가입 기능

가장 회원 가입이 되기 위한 조건은

1. 사용 가능한 ID (사용중인 ID 사용 불가)

2. 비밀번호 확인 (비밀번호가 같아야 함)

3. 이름과 닉네임이 같으면 안된다.(필요할 것 같아서 넣음)

4. 회원가입

이렇게 3가지가 필요하다.

1. 사용 가능한 ID

사실 기본 회원가입과 비슷하게 ID를 입력 후 중복체크하는 버튼을 만드려고 했다.

하지만, 우리가 만든 디자인과는 중복체크 버튼은 어울리지 않았고, 결국 keyup 기능을 이용하여 중복체크를 하기로 했다.

$('.idInput').on("propertychange change keyup paste input", function(){
  // console.log("keyup 테스트");
  var userId = $(".idInput").val();
  var data = {userId : userId}

  $.ajax({
    type: "post",
    url: "/check/id",
    data : data,
    success : function(result){
      //사용 가능
      if(result === 0){
        $(".condition1").css("display", "flex");
        $(".id_input_re_1").css("display","inline-block");
                $(".id_input_re_2").css("display", "none");
        console.log("사용 가능");
      }
      // 아이디 중복
      if(result === 1){
        $(".condition1").css("display", "flex");
        $(".id_input_re_1").css("display","none");
                $(".id_input_re_2").css("display", "inline-block");
        console.log("아이디 중복!");
      }
    }
  });
});

propertychange change keyup paste input을 이용하여 input값에 입력되는 값을 실시간으로 처리할 수 있도록 만들었다.

이후 ajax를 이용하여 ID 중복체크 메서드를 실행시켜 사용 가능한지 중복인지 판별하는 기능을 만들었다.

service 부분

public int checkDuplicateNickName(String userNickName) {
        Optional<UserEntity> find = userRepository.findByUserNickName(userNickName);
        if(find.isEmpty()){
            System.out.println("possible NickName!!");
            return 0;
        }
        else{
            System.out.println("duplicate NickName!!");
            return 1;
        }
    }

keyup 된 ID를 가져와서 만약 해당 ID를 갖고 있는 사용자가 있다면, 1을 반환하고, 사용가능한 아이디라면 0을 반환하도록 만들었다.

2. 비밀번호 체크

대부분 회원가입 페이지를 보면 비밀번호를 누르고 한번더 비밀번호를 입력하라고 한다.

그 부분을 만들었다.

이 부분은 회원가입을 누를 때 체크하는 기능으로, 비밀번호와 한번더 입력한 비밀번호 값이 같지 않다면 회원가입이 되지 않게 만들었다.

$(document).ready(() => {
  $("button").click((event) => {
    var password = $(".passwordInput").val();
    var passwordCheck = $(".passwordCheckInput").val();

    if(password !== passwordCheck) {
      $(".condition2").css("display", "");
      event.preventDefault();
    }
    if(password === passwordCheck) {
      $(".condition2").css("display", "none");
    }
  })
})

해당 input 값들을 가져와 같은지 판별하였다.

3. 이름과 닉네임이 같으면 안된다.

이 부분도 2번과 똑같이 두 input 값을 가져와 비교하여 판별하였다.

$(document).ready(() => {
  $("button").click((event) => {
    var nameVal = $(".nameInput").val();
    var nickNameVal = $(".nickNameInput").val();
    if (nameVal === nickNameVal) {
      $(".condition").css("display", "");
      event.preventDefault();
    }
    if (nameVal !== nickNameVal) {
      $(".condition").css("display", "none");
      event.preventDefault();
    }
  });
});

4. 회원 가입

모든 유효성 검사에 가능해지면 회원가입을 할 수 있다.

회원 가입은 ajax를 통해 회원가입이 이루어지게 만들었다.

$(document).ready(() => {
  $(".join_button").click((event) => {
    var nameVal = $(".nameInput").val();
    var nickNameVal = $(".nickNameInput").val();
    var password = $(".passwordInput").val();
    var passwordCheck = $(".passwordCheckInput").val();

    var userId = $(".idInput").val();
    var data = {
      userId : $(".idInput").val(),
      userNickName : $(".nickNameInput").val()
    };

    $.ajax({
      type: "post",
      url: "/check",
      data : data,
      success : function(result){
        if(nameVal !== nickNameVal){
          if(password === passwordCheck){
            if(result === 3){
              alert("회원가입되었습니다.");
              document.getElementById("signup").submit();
            }
            else if(result === 2){
              alert("닉네임이 중복됩니다.");
            }
          }
        }
      }
    })
  })
})

회원가입에 필요한 input값들을 data 로 만들어 ajax로 서버에 보낸다.

그후 js로만 만든 유효성 검사를 if문으로 판별한 후 서버에서 받아온 값을 또 확인 하여 회원가입 시켰다.

이때 서버에서 받아오는 값은 아이디 닉네임이 중복되는지 안되는지를 판별하는 것이다.

회원가입은 form태그를 이용하여 설정하였다.

 @PostMapping("/check")
    public ResponseEntity<Integer> checkIdAndNick(@RequestParam String userId, @RequestParam String userNickName){
        int checkId = userService.checkDuplicateId(userId);
        int checkNick = userService.checkDuplicateNickName(userNickName);
        //아이디 닉네임 둘다 중복될 때
        if(checkId == 1 && checkNick == 1){
            return new ResponseEntity<>(0, HttpStatus.BAD_REQUEST);
        }
        //아이디 중복될 때
        if(checkId == 1 && checkNick == 0){
            return new ResponseEntity<>(1, HttpStatus.BAD_REQUEST);
        }
        //닉네임 중복될 때
        if(checkId == 0 && checkNick == 1){
            return new ResponseEntity<>(2, HttpStatus.OK);

        }
        //아이디 닉네임 둘다 사용 가능할 때
        if(checkId == 0 && checkNick == 0){
            return new ResponseEntity<>(3, HttpStatus.OK);   
        }
        else
            return new ResponseEntity<>(null, HttpStatus.BAD_GATEWAY);

    }

이렇게 회원가입 부분을 만들었다.

로그인 기능

로그인 기능은 아주 쉽게 만들었다.

function login() {
  var idInput = document.querySelector(".idInput").value;
  var passwordInput = document.querySelector(".passwordInput").value;

  let data = {
    userId: $(".idInput").val(),
    userPassword: $(".passwordInput").val(),
  };
  $.ajax({
    type: "POST",
    url: "/login",
    data: JSON.stringify(data),
    contentType: "application/json; charset=utf-8",
    dataType: "json",
    success: function (response) {
      alert("로그인 되었습니다.");
      window.location.replace("/"); // Redirect to the main page
    },
    error: function () {
      alert("존재하지 않는 정보입니다.");
      window.location.href = "/login";
    },
  });
}

ID와 비밀번호 input 값을 가져와 서버에 반환해 로그인 시키는 기능이다.

핑계라고 생각하면 핑계이겠지만, 마지막으로 회고록을 쓴 후, 한동안 이 프로젝트를 하지 못했다.

가장 큰 이유로, 이 프로젝트는 나 혼자 하는 것이 아닌, 여러명이서 함께하는 팀 프로젝트이다.

서버 개발과 페이지 퍼블리싱이 끝난 상태였지만, 기말고사 기간이라 바로 js 작업 및 타임리프 작업에 들어가지 못했다.

기말고사가 끝난 후 종강을 하며 방학 기간에 돌입하면서, 회의를 진행했었다.

시간이 많이 지체 되었다. 사실상 3개월이면 끝날 수 있는 프로젝트를 질질 끌고 있었으니..

물론 나의 잘못도 있다.

사실상 학교 커리큘럼에 프로젝트를 진행하는 것도 없었고, 나도 중요하지만, 후배들도 프로젝트를 진행해보면서, 자신의 실력도 늘릴 수 있는 쉽게 말해 개발 공부를 제대로 하고 싶은 사람들을 도와 함께 진행 하고 싶었다.

그렇다 보니, 이제 처음 프로젝트를 접한 팀원들과 할라니 시간이 지체되었던 것 같다.

그리고, 사실상 PM인 내가 기말고사 일정 때문에 지체될것을 몰랐고, 그로인해 일정 조율등을 잘하지 못한 나의 잘못도 있다.

그래서 종강 후 첫 회의에서 나는 단도직입적으로 요번 7월달까지 마무리했으면 좋겠다고 말했다.

대학교 4학년인 나는 사실 마음이 조급했다.

같이 프로젝트를 진행하는 팀원(후배)도 나의 마음을 이해했는지, 최대한 노력해서 끝내보자고 얘기를 하였고, 오늘 8월 4일 드디어 잔 수정을 남겨놓고 모두 끝마쳤다.

사실 그냥 서버쪽만 신경쓰려했던 나는 조급한 마음 때문에 프론트 부분도 함께 진행하였다.

7월 한달동안 이 프로젝트를 끝내기 위해 열심히 달려왔다.

회고록을 쓰지 못할 정도로 시간 투자를 많이 해서 끝내왔다.

하지만 또 이렇게 복습을 하며 회고록을 쓰지 않는다면, 결국 7월 한달동안 내가 했던 것이 물거품이 될 수도 있기 때문에, 회고록을 다시 작성하려고 한다.

이제 배포 준비를 해야하기 때문에 또 바쁠 예정이다. 하지만 이렇게 바쁘게 살다보니, 내가 살아있는 느낌이 든다.

역시 나는 뭔갈 해야되는 사람인가 보다.

아무튼 다음 회고록부터 내가 프로젝트를 진행하면서, 해왔던 작업이나, 문제, 내가 겪었던 생각들을 적어볼 생각이다.

얼른 배포까지 마무리하여 내가 만든 첫 프로젝트를 세상에 내보내고 싶다.

UriComponentsBuilder

인터넷상에 존재하는 모든 자원(Resource)은 URI를 이용하여 그 위치를 나타내게 된다.

따라서, 웹 애플리케이션을 개발할 때 어떤 데이터를 리턴해주기 위해서 내부적으로 URI를 이용해 요청을 전송하게 된다.

UriComponentsBuilder는 이러한 URI를 작성할 때 실수를 범하거나 유지보수 측에서 유리하게 작성하기 위해 사용하는 클래스이다.

UriComponentsBuilder는 UriComponents들을 쉽게 작성하기위해 만들어진 builder 클래스이다.

Static Factory Method 중에 하나를 이용하여 UriComponentsBuilder 객체를 생성한다.

1. Static Factory Method의 종류는 아래와 같다.

   • newInstance()

   • fromPath(String)

   • fromUri (URI)

   • fromUriString (String)

   • fromHttpUrl (String)

   • fromHttpRequest (HttpRequest)

   • fromOriginHeader (String)

2. 대응되는 각 메서드를 이용하여 URI 구성요소를 설정하거나 인코딩을 설정한다.

   • scheme(String)

   • userInfo(String)

   • host(String)

   • port(String or int)

   • path(String)

   • queryParam(String, Object...)

   • queryParams(MultiValueMap<String, String>)

   • fragment(String)

   • encode(void or Charset) : void일 경우 UTF-8 로 인코딩

   • expand(Map<String, ?> or Object... or UriTemplateVariables) : URI 템플릿 변수 값을 지정

3. build() 메서드를 이용하여 UriComponents 인스턴스를 Build 한다.

   또는 buildAndExpand() 메서드를 이용하여 URI 템플릿 변수를 설정한 후 Build한다.

   이후 toUri()를 통하여 URI 객체로 변환 시킨다.

// 1. 간단한 링크 생성
UriComponents uriComponents1 = UriComponentsBuilder.newInstance()
    .scheme("https").host("blog.naver.com/aservmz").path("/222313864092").build(); 
    // https://blog.naver.com/aservmz/222313864092

//  2. URI 인코딩
UriComponents uriComponents2 = UriComponentsBuilder.newInstance()
    .scheme("http").host("www.example.com").path("/encodeTest test").build().encode();
    // http://www.example.com/encodeTest%20test

//  3. path 내에 템플릿 변수설정 방법 => path() 내에 {}로 변수명 지정 후 buildAndExpand()메서드에서 값 설정
URI uriComponents3 = UriComponentsBuilder.newInstance()
    .scheme("http").host("www.example.com").path("/{키워드는}/{아무렇게나 지정해도 됩니다.}")
    .buildAndExpand("UriTemplate", "setting")
    .toUri();
    // http://www.example.com/UriTemplate/setting

// 4. Query Parameter가 포함된 URI 생성
URI uriComponents4 = UriComponentsBuilder.newInstance()
    .scheme("http").host("www.example.com").path("/{경로}")
    .query("q={queryValue1}").query("p={queryValue2}").buildAndExpand("testPath", "value1", "value2")
    .toUri();
    // http://www.example.com/testPath?q=value1&p=value2

// 5. toUriString()을 이용한 방법
UriComponents uriComponents5 = UriComponentsBuilder
    .fromUriString("https://example.com/test/{testVariable}")
    .queryParam("q", "{q}").encode().buildAndExpand("test", "12345");
    // https://example.com/test/test?q=12345

이후 인코딩 시에는 항상 UriComponentsBuilder안에서 인코딩을 해야한다.

ServletUriComponentsBuilder

ServletUriComponentsBuilder 클래스는 UriComponentsBuilder클래스를 상속하고 있다.

UriComponentsBuilder는 직접 URI를 생성 및 인코딩 한다면, ServletUriComponentsBuilder는이전 요청의 URI를 재사용하여 보다 편리하게 URI를 사용할 수 있도록 하는 클래스이다.

• fromContextPath(HttpServletRequest)

• fromServletMapping(HttpServletRequest)

• fromRequestUri(HttpServletRequest)

• fromRequest(HttpServletRequest)

// 이 메서드들은 요청 객체를 RequestContextHolder로부터 얻는다는 점을 제외하고 위의 메서드들과 동일합니다.

• fromCurrentContextPath()

• fromCurrentServletMapping()

• fromCurrentRequestUri()

• fromCurrentRequest()

@PostMapping("/users")
    public ResponseEntity<User> createUser(@RequestBody User user) {
        User savedUser = service.save(user);

        URI location = ServletUriComponentsBuilder.fromCurrentRequest()
                .path("/{id}")
                .buildAndExpand(savedUser.getId())
                .toUri();

        return ResponseEntity.created(location).build();
    }

fromCurrentRequest()

• 현재 요청된 Request 값을 가져옴
• ex) localhost:8080/users

path("/{id}")

• 이후 URI 경로 설정

buildAndExpand(savedUser.getId())

• 위에서 결정한 파라미터 값 생성

toUri()

• URI로 변경

이렇게 URI를 만들 수 있다.

여기서 URI를 생성해서 반환하는 이유는

하나의 데이터를 생성한 후 데이터의 상세정보를 볼 때 id값을 다시한번 서버에 물어봐야 한다.

하지만 해당 URI를 반환시킨다면, 다시 물어보는 만큼의 네트워크 트래픽을 줄일 수 있기 때문에 사용하는 것이다.

ResponseEntity

RestAPI에서 상태코드와 함께 반환할 때 ResponseEntity를 사용한다.

ResponseEntity에서는 URI를 반환할 때, 필요한 상태코드들을 메서드로 제공한다.

created(201) 뿐만 아니라, accepted(202), noContent(204), badRequest(400), internalServerError(500), notFound(404) 등 자주 쓰이는 상태코드를 가독성 좋은 메소드로 제공한다.

따라서 반환 값을

return ResponseEntity.created(location).build();

로 만든 것이다.

이렇게 상태코드를 200번의 상태코드만이 아닌 다양한 상태코드를 사용하여 상태를 반환할 수 있다.

참고 https://velog.io/@jakeseo_me/Spring-Boot%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-RESTful-Web-Services-%EA%B0%9C%EB%B0%9C-14-HTTP-Status-Code-%EC%A0%9C%EC%96%B4 https://blog.naver.com/PostView.naver?blogId=aservmz&logNo=222322019981

가상화란 물리적 자원인 하드웨어를 효율적으로 활용하기 위해서 하드웨어 공간 위에 가상의 머신을 만드는 기술이고, 컨테이너란 컨테이너가 실행되고 있는 호스트 os의 기능을 그대로 사용하면서 프로세스를 격리해 독립된 환경을 만드는 기술을 뜻한다.

사실, 도커가 세상에 나오기 전 컨테이너 기술은 이미 있었다.

가상머신과 도커 비교

가상머신(Virtual Machines)

기존의 가상화 기술인 가상머신(Virtual Machines)은 하이퍼바이저(Hypervisor)를 이용해 여러개의 운영체제를 하나의 호스트에서 생성해서 사용하는 방식이었다.

하이퍼바이저는 호스트 하드웨어에 설치되어 호스트와 게스트를 나누는 역할을 하고, 각각의 게스트는 하이퍼바이저에 의해 관리되며 시스템 자원을 할당받게 된다.

이 때 하이퍼바이저에 의해 생성된 게스트는 호스트나 다른 게스트와 상호 간섭하지 않고 완전히 분리된 환경에서 구동된다.

하이퍼바이저를 활용하면 마치 하드웨어가 여러 개인 것처럼 하나의 서버를 여러 명이 나눠 쓸 수도 있고, 컴퓨터 한 대에서 서로 다른 OS를 동시에 사용할 수도 있다.

이러한 가상화 방식을 사용하는 툴은 VirtualBox, VMware 등이 있다.

하지만, 이러한 가상화 방식은 기존OS 위에 OS를 실행하는 것이므로 리소스(CPU, 메모리 등)을 할당하는데 작업이 필요하고, 게스트 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기 때문에 가상 머신을 배포하기 위한 이미지로 만들었을 때 이미지의 크기 또한 커진다.

즉, 가상 머신은 완벽한 운영체제를 생성할 수 있다는 장점은 있지만 일반 호스트에 비해 성능 손실이 있으며, 수 기가바이트에 달하는 가상 머신 이미지를 애플리케이션으로 배포하기는 부담스럽다는 단점이 있다.

정리

• 가상머신은 Hypervisor를 통해 여러개의 운영체제를 생성되고 관리됨. (Guest OS)

• 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 HyperVisor를 거치므로 -> 성능 손실이 큼 ↑

• 가상머신은 Guest OS를 사용하기 위한 라이브러리, 커널 등을 포함하므로 -> 배포할 때 용량이 큼 ↑

이러한 기술을 대체한 것이 바로 도커이다.

MSA(Micro Seivice Architecture)

사실 요즘 MSA(Micro Service Architecture)가 대세로 떠오르면서 MSA의 단점인 관리의 복잡성을 해결해주기 위해 서비스의 컨테이너화가 이루어지고, 이 과정에서 Docker와 Kubernetes가 많이 도입되었다.

MSA(Micro Service Architectur)란 간단하게 설명하자면, 서비스간의 의존성을 없애고 기능을 쪼개는 것을 중점적으로 설계한 아키텍처이다.

하나의 통합된 프로그램이 아닌 비슷한 기능을 가진 것들을 잘게 쪼개서 만든 것이다.

이런 방식의 아키텍처는 새로운 서비스 개발 시(기능 업데이트) 필요한 기능 부분만 수정하여 비교적 간편하게 작업을 경량화 시킬 수 있다.

전체적인 그림에서 서비스간 결합도(Coupling)를 줄이고 응집도(Cohesion)를 높이는 효과를 볼 수 있다.

MSA에 이런 장점들이 있는 반면에, 서비스들을 관리하기 복잡하다는 단점이 있다.

도커를 사용하면 이런 문제를 쉽게 해결할 수 있다.

도커(Docker)

도커 컨테이너는 가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스(namespace), cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다.

컨테이너에 필요한 커널을 공유해서 사용하고, 컨테이너 안에는 어플리케이션을 구동하는 데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 컨테이너를 이미지로 만들었을 때 이미지의 용량 또한 가상 머신에 비해 대폭 줄어든다.

따라서 컨테이너를 이미지로 만들어 배포하는 시간이 가상 머신에 비해 빠르며, 가상화된 공간을 사용할 때의 성능 손실도 거의 없다는 장점이 있다.

• 도커 컨테이너는 가상화된 공간을 생성할 때 리눅스 자체 기능을 사용하여 프로세스 단위의 격리 환경을 만드므로 -> 성능 손실 없음 無

• 가상머신과 달리 커널을 공유해서 사용하므로, 컨테이너에는 라이브러리 및 실행파일만 있으므로 -> 용량이 작음 ↓

• 위의 이유로 -> 컨테이너를 이미지로 만들었을 때

  배포하는 시간이 가상 머신에 비해 빠르며 ↑, 사용할 때의 성능 손실 또한 거의 없음 ↓

도커를 사용하는 이유

가상머신에 비해 월등히 뛰어나다, 도커는 단점이 없다. 이런 뜻이 아니다. 때에 따라 경우에 따라 사용하는 환경이 다를 뿐이다.

어떤 때에 도커를 사용하는 것일까?

가장 첫번째로 위에 말했듯이 MSA환경을 구축할 때 도커를 주로 이용한다.

도커를 사용하게 되면 IaC(Infrastructure as Code)가 가능 하다.

Docker의 진짜 큰 힘은 인프라를 코드화해서 관리할 수 있다는 점이다.

Dockerfile이나 docker-compose를 만져보면 이전에는 직접 시스템을 세팅해줘야 하는 부분들을 코드로 편리하게 관리할 수 있는 것을 볼 수 있다.

두번째로 도커는 테스트, 스테이징, 배포 등 여러 용도로도 사용 가능하다.

테스트 환경, 스테이징 환경, 배포 환경등이 개발환경과 다를 수 있다.

각각의 환경들을 하나의 레거시 환경에서 돌리게 된다면, 수많은 오류를 마주할 수 있다.

결국 도커를 사용하여 여러 환경에 맞추어 애플리케이션을 컨테이너화 시키면, 개발과 배포의 흐름이 매우 간단해져서 빠르게 진행될 수 있다.

서버의 운영체제나 미들웨어의 의존성에 대해 걱정할 필요없이 Docker만 설치되어 있다면 모든 것이 해결된다.

또한 배포 후, 애플리케이션 사용자 수가 늘어나면 해당 인프라를 확장할 시 scale-out에 매우 큰 도움이 될 수 있다.

결국 우리는 이러한 개발환경에 익숙해져야 하고 잘 쓸줄 알아야 한다.

곧 개발단계가 끝나가는 프로젝트가 있는데, 도커와 aws를 통해 배포해볼 예정이다.

해당 프로젝트를 배포하기전에 docker와 aws에 대해 자세히 알아볼 예정이다.

References https://myjamong.tistory.com/297 https://velog.io/@markany/%EB%8F%84%EC%BB%A4%EC%97%90-%EB%8C%80%ED%95%9C-%EC%96%B4%EB%96%A4-%EA%B2%83-1.-%EB%8F%84%EC%BB%A4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80 https://seosh817.tistory.com/345#Virtual%20Machine(%EA%B0%80%EC%83%81%EB%A8%B8%EC%8B%A0)%20vs%20Docker%20Container(%EB%8F%84%EC%BB%A4%20%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88)-1

일대다 관계는 위에서 봤던 @OneToMany다. 하지만 만약 @OneToMany로 단방향 관계를 맺는다면 어떻게 될까?

다시 말해 @OneToMany 어노테이션이 있는 필드에 @JoinColumn을 아래 코드처럼 건다면 어떻게 될까?

@Entity
public class Team {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String teamName;
    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
}

해당 엔티티는 일대다 단방향 연관관계 매핑을 한 것이다.

하지만, 해당 외래키는 다쪽인 Member에 생긴다.

애당초 @OneToMany 어노테이션은 외래키 생성을 할 수 없다.

그래서 일대다 단방향 연관관계는 권장되지 않는다.

왜냐하면 연관관계 주인 엔티티에서 외래키를 관리하지않고 반대편 엔티티에서 외래키를 관리하기 때문에(데이터베이스 설계에서 1:M관계에서 외래키는 M에 존재하기 때문에) 관리가 부담스럽다.

일대다 양방향 연관관계

일대다 양방향 연관관계는 애초에 다대일 양방향 연관관계와 같기 때문에 존재하지 않는다.

일대일 단방향 연관관계

일대일 관계는 양쪽이 서로 하나의 관계만 가지는 관계이다.

일대일 관계에서는 외래키가 어디에 있든 상관이 없다.

Member 엔티티와 Locker 엔티티가 있고, 1:1 관계라 하자.

외래키는 Member 또는 Locker 엔티티에 존재할 수 있다.

연관관계 주인을 Member로 한 1:1 단방향 관계 코드를 보자.

@Entity
public class Locker {
    @Id
    @GeneratedValue
    private Long id;
    private String name;
}

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String memberName;

    @OneToOne
    @JoinColumn(name = "LOCKER_ID")
    private Locker locker;
}

일대일 단방향 관계도 다대일 단방향과 비슷하다

Locker를 단방향 관계 주인으로 하고 싶으면 @OneToOne을 Locker에 붙여주면 된다.

단지 일대일 단방향 관계는 어디든 주인이 될 수 있다는 점이 특징이다.

반대로 Locker가 연관관계의 주인이 될 수 있다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String memberName;
}

@Entity
public class Locker {
    @Id
    @GeneratedValue
    private Long id;
    private String lockerName;

    @OneToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;
}

일대일 양방향 연관관계

일대일 양방향 관계도 다대일 양방향 관계랑 비슷하다. 바로 코드를 보자.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String memberName;

    @OneToOne(mappedBy = "member")
    private Locker locker;
}

@Entity
public class Locker {
    @Id
    @GeneratedValue
    private Long id;
    private String lockerName;

    @OneToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;
}

만약 Member 객체가 연관관계의 주인으로 설정하고 싶다면 mappedBy 속성을 변경해주면 된다.

다대일 단방향 연관관계

RDBMS에서는 다대다 관계를 2개의 테이블을 이용해 표현이 불가능하다.

그래서 중간에 관계 테이블을 두어 일대다, 다대일 관계로 표현한다.

하지만 객체는 테이블과 다르게 객체 2개로 다대다 연관관계를 만들 수 있다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String userName;

    @ManyToMany
    @JoinTable(name = "MEMBER_PRODUCT",
    joinColumns = @JoinColumn(name = "MEMBER_ID"),
    inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID"))
    private List<Product> product = new ArrayList<>();
}

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String productName;
}

@ManyToMany

• 다대다 매핑을 위한 어노테이션

@JoinTable

• 연결 테이블을 매핑하기 위한 어노테이션

<@JoinColumn 속성>

• @JoinTable.name: 연결 테이블을 지정한다.
• @JoinTable.joinColumns: 현재 방향인 회원과 매핑할 조인 컬럼 정보 지정
• @JoinTable.inverseJoinColumns: 반대방향인 Product와 매핑할 조인 컬럼 정보 지정

MEMBER_PRODUCT 테이블은 다대다 관계를 일대다, 다대일 관계로 풀어내기 위해 필요한 연결 테이블일 뿐이기 때문에, 다대다 관계를 사용할 때는 이 연결 테이블을 신경쓰지 않아도 된다.

다대다 양방향 연관관계

위의 매핑들 처럼 반대 객체에 @ManyToMany(mappedBy = "")을 사용해 양방향 연관관계를 시킨다.

@Entity
public class Product {
    @Id
    @GeneratedValue
    private Long id;
    private String productName;
    @ManyToMany(mappedBy = "product")
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String memberName;

    @ManyToMany
    @JoinTable(name = "MEMBER_PRODUCT",
    joinColumns = @JoinColumn(name = "MEMBER_ID"),
    inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID"))
    private List<Product> product = new ArrayList<>();
}

역시나 mappedBy 속성이 없는 부분이 연관관계의 주인이다.

양방향으로 연관관계를 매핑했으니 객체 그래프 탐색을 이용해 product.getMembers()를 사용해 역방향으로도 조회할 수 있다.(단방향 관계시 member.getProducts()만 사용해 객체 그래프 탐색 가능)

다대다: 한계

위의 예제처럼 다대다 연관관계를 사용하면 좋겠지만, 실무에서는 다대다 연관관계를 사용하기에는 한계가 있다.

만약 회원이 상품을 주문할 때 주문 수량이나, 날짜같은 컬럼이 추가가 된다.

이렇게 컬럼이 추가 되면 더이상 @ManyToMany를 사용할 수 없다.

결국 연결 테이블과의 일대다, 다대일 연관관계를 이용해 매핑해야 한다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String memberName;

    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProduct = new ArrayList<>();
}

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String productName;
}

Member 객체와 MemberProduct 객체와는 양방향 관계지만, Product 객체와 MemberProduct는 단방향 관계이다.

상품 엔티티에서 회원상품 엔티티로 객체 그래프 탐색 기능이 필요하지 않다고 판단되었기 때문에 단방향으로 연관관계를 맺었다.

가장 중요한 회원상품 엔티티를 보자.

복합 기본키 사용

회원상품 엔티티

@Entity
@IdClass(MemberProductId.class)
public class MemberProduct {
    @Id
    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @Id
    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;

    private String orderAmount;
}

회원상품 식별자 클래스

public class MemberProductId implements Serializable {
    private Long member;
    private Long product;

    @Override
    public int hashCode() {
        return super.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
        return super.equals(obj);
    }
}

회원상품 엔티티를 보면 기본키를 매핑하는 @Id와 외래키를 매핑하는 @JoinColumn을 동시에 사용해 기본 키 + 외래 키를 한번에 매핑했다.

그리고 @IdClass 어노테이션을 사용해 복합 기본 키를 매핑했다.

<복합 기본키>

• 복합 기본키를 사용하려면 별도의 식별자 클래스가 필요하다.
• Serializabel을 구현해야 한다.
• equals와 hashCode 메소드를 구현해야 한다.
• 기본 생성자가 있어야 한다.
• 식별자 클래스는 public 이어야 한다.
• @IdClass를 사용하는 방법 외에 @EmbeddedId를 사용하는 방법도 있다.

이렇게 회원과 상품의 기본 키를 받아 자신의 기본키로 사용하고 외래 키로도 사용하는 것을 식별 관계라고 한다.

하지만 복합 기본 키를 사용하는 방법은 복잡하기 때문에 새로운 키를 사용해 복합 기본 키를 생성하지 않고 매핑하는 것이다.

마치 연결테이블이 새로운 테이블을 만드는 것처럼 사용하는 것이다.

새로운 기본 키 사용

DB에서 자도으로 생성해주는 대리 키를 Long 값으로 사용헤 기본키를 설정 하는 것이다.

해당 방법은 간편하고 거의 영구히 쓸 수 있으며 비즈니스에 의존하지 않는다.

또한 ORM매핑 시 복합키를 만들지 않아도 되므로 간단히 매핑을 완성 할 수 있다.

새로운 ORDER_ID라는 기본키를 만들어 다시 매핑 해보자.

@Entity
public class Order {

    @Id
    @GeneratedValue
    @Column(name = "ORDER_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;

    private int orderAmount;
}

개인적인 나의 의견

가장 처음 JPA 공부를 할 때, 궁금한 점이 있었다.

만약 회원(1)과 주문(N)간의 매핑을 할 때, 회원의 주문 목록을 들여오기 위해서는 양방향 연관관계를 써야 member.getOrders()로 객체 그래프 탐색을 이용해 주문 목록을 받아 올 수 있다고 생각을 했다.

하지만, 실무에서는 다대일 단방향 연관관계를 사용해도 해당 회원의 주문 목록을 가져올 수 있다는 것이다.

나는 회원의 주문 목록을 가져오기 위해서는 테이블에서 뿐만 아니라, 객체에서도 객체 그래프 탐색을 이용하여 받아와야지만 가능한 줄 알았다.

하지만, 객체 그래프 탐색을 이용하지 않고, 테이블의 양방향 연관관계로 회원Id를 이용해 가져올 수 있다고 알게 되었다.

처음에 나는 객체도 양방향으로 연관관계를 매핑하지 않으면 객체지향의 특징을 잃어 버리는 것인 줄 알았다.

구글링 해본 결과, 양방향으로 매핑하는 이유는 따로 있었다.

양방향 매핑이 필요한 이유

<양방향 매핑이 필요한 이유>

• 양방향 매핑이 필요한 경우는 단방향 매핑된 관계를 역방향으로 조회할 때다.

• 데이터에 대한 일관성을 유지할 때 사용된다.

• 개발을 하다보면 단방향으로 매핑된 연관 관계를 역순으로 조회해야 하는 경우가 발생한다.

• 이처럼 필요한 경우에 한하여, 양방향 매핑을 추가적으로 구현하는 것을 권장한다.

결국 객체에서의 연관관계를 역순으로 조회할 때 양방향 매핑이 필요한 것이었다.

그게 아니면 단방향으로도 사용 가능하다는 것을 알게 되었다.

그래서 처음 설계시 대부분 단방향으로 사용하고 양방향으로 구현하지 않는 것이 좋다.

이렇게 하나 또 알게 되면서 지식이 늘어나는 것이 행복하다.

현재 우리는 SQL Mapper나 ORM 기술들을 이용하여, DB와 연결하여 사용하고 있다.

이중 JPA는 자바 진영의 ORM 기술 표준으로, 과거 JDBC API를 사용해 매핑을 해주던 것을 보다 간결하게 만들어주는 프레임워크이다.

뭐 이전보다 SQL문을 덜 쓴다는 것에 대해 장점을 가져서 JPA를 사용하는 것도 있지만, 가장 큰 문제는 따로있다.

바로 객체와 DB와의 패러다임의 불일치 문제를 해결하기 위해 사용하는 것이다.

객체와 DB와의 패러다임 불일치

자바같은 객체 지향 언어는 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 다양한 장치들을 제공한다.

특히 객체들 간에는 참조를 통해 다른 객체와 연관관계를 가지고, 참조에 접근해 연관된 객체를 조회한다.

반면, 테이블은 외래키(foreign key)를 이용해 다른 테이블과 연관관계를 가지고 조인을 사용해 연관된 테이블을 조회한다.

객체들은 참조가 있는 방향으로만 조회할 수 있다. 하지만 DB의 외래키들은 양방향으로 조회가 가능하다.

결국 우리는 FK, 외래키를 이용한 테이블에 맞춘 객체 모델을 사용해서, DB 테이블을 모델링했다.

class Member{

    String id;        // MEMBER_ID 컬럼 사용
    Long teamId;    // TEAM_ID FK 컬럼 사용
    String username;
}

class Team{

    Long id;        // TEAM_ID PK 사용
    String name;
}

이렇게 객체를 테이블에 맞추어 모델링하면 객체를 테이블에 저장하거나 조회할 때는 편하지만, 객체에서는 연관된 객체의 참조를 보관해야 참조를 통해 연관된 객체를 찾을 수 있다.

이렇게 되면 좋은 객체 모델링은 기대하기 어렵고 결국 객체지향의 특징을 잃어버리게 된다.

결국 객체지향의 특징을 잃지 않고 테이블을 모델링 하기위해 JPA라는 것이 필요한 것이다.

참조를 사용하는 객체 모델

class Member{

    String id;        // MEMBER_ID 컬럼 사용
    Team team;        // 참조로 연관관계를 맺는다.
    String username;

    Team getTeam() {
        return team;
    }
}

class Team{

    Long id;        // TEAM_ID PK 사용
    String name;
}

이처럼 참조를 사용하는 객체모델을 사용하면 객체를 테이블에 저장하거나 조회하기 쉽지 않다.

Member 객체는 team 필드로 연관관계를 맺고 Member 테이블은 TEAM_ID로 연관관계를 맺기 때문인데, 객체 모델은 외래키가 필요 없고 단지 참조만 있으면 된다.

반면에 테이블은 참조가 필요없고 외래키만 있으면 된다.

결국, 우리는 JPA를 이용해서 변환역활을 해야 한다.

연관관계 매핑

객체는 참조를 사용해서 관계를 맺고, 테이블은 외래키를 사용해 관계를 맺는다.

이러한 연관관계들을 매핑하는 것이 JPA의 역할이다.

키워드

연관관계의 매핑을 이해하기 위해 세가지의 키워드가 있다.

방향

• [단방향, 양방향]
• 회원과 팀이 관계가 있을 때, 회원 -> 팀, 팀 -> 회원 둘중 한 쪽만 참조하는 것을 단방향관계, 양쪽 모두 서로 참조하는 것을 양방향 관계라 한다.
• 방향은 객체관계에만 존재, 테이블 관계는 항상 양방향이다.

다중성

• [다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)]
• 회원과 팀이 관계가 있을 때, 여러 회원은 한팀에 속한다. 따라서 회원과 팀은 다대일 관계다.
• 반대로 팀과 회원은 일대다 관계이다.

연관관계의 주인

• 객체를 양방향 연관관계로 만들면 연관관계의 주인을 정해야 한다.

단방향, 양방향 연관관계

단방향

이 전에 말했듯, 객체는 단방향으로 관계를 맺고, 테이블은 양방향으로 관계를 맺는다.

테이블은 항상 양방향으로 관계를 맺기 때문에, JPA에서 나오는 연관관계의 방향을 객체들의 방향을 의미한다.

예를 들어 Member와 Team 객체가 있다고 가정하자.

• 회원은 하나의 팀에만 소속될 수 있다.
• 회원과 팀은 다대일 관계이다.

• 객체 연관관계
  • 회원 객체는 Member.team 필드로 팀객체와 연관관계를 맺는다.
  • 따라서 현재 Member와 team 객체는 단방향 관계이다.
  • 단방향 관계이므로, member.getTeam()으로 조회가 가능하지만, team.getMembers()는 불가능하다.

• 테이블 연관관계
  • 회원 테이블은 TEAM_ID 외래 키로 Team 테이블과 연관관계를 맺는다.
  • 테이블은 항상 양방향 관계이다. 따라서 Member Join Team과 Team Join Member 둘다 가능하다.

따라서 객체 그래프 탐색으로 Member 에서 Team을 조회할 수 있지만, Team에서는 Member를 조회할 수 없다.

양방향

그렇다면 객체 연관관계도 양방향으로 만들면 되는 것이 아닐까라는 생각을 할 것이다.

테이블도 외래키로의 연관관계를 이용해 양방향으로 만드니 객체에서도 양방향으로 만들면 되는거 아니야? 싶을 것이다.

가능하다.

팀에서 회원을 조회할 수 있게 양방향 연관관계로 만들 수 있다.

테이블은 양방향 연관관계이다. 하지만 객체에서의 연관관계는 양방향처럼 보일지라도, 결국 단방향인 것이 2개인 것이다.

엄밀히 말하면 객체에는 양방향 연관관계라는 것이 없다.

이렇게 단방향과 양방향의 차이를 알아보았다.

이제는 다중성과 방향을 동시에 알아보자.

다대일 단방향 연관관계

가장 먼저 코드를 통해 확인해보자

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;
    private String MemberName;
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;
}

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;
    private String teamName;
}

• 객체 연관관계: 회원 객체의 Member.Team 필드 사용
• 테이블 연관관계: 회원 테이블의 MEMBER.TEAM_ID 외래키 컬럼을 사용

단방향 연관관계에서의 객체와 테이블이 사용할 수 있는 연관관계를 나타내었다.

객체 연관관계는 단방향으로 되어있기 때문에 Team.Member 필드를 사용할 수 없다.

반면에 테이블은 외래키를 이용해 양방향으로 조회를 할 수 있다.

@ManyToOne

• 다대일 연관관계를 확인 시키는 어노테이션
• 현재 Member 객체가 다 쪽이기 때문에 다대일 연관관계 어노테이션을 사용한 것이다.

@JoinColumn(name="TEAM_ID")

• 해당 필드를 외래키로 설정하겠다는 어노테이션이다.

다대일 양방향 연관관계

양방향 연관관계 매핑 코드는 다음과 같다.

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;
    private String teamName;
    //양방향 매핑을 위해 추가
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;
    private String MemberName;
    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;
}

단방향 연관관계와 다르게 Team필드에 Member를 저장할 수 있는 필드가 생성된 것을 볼 수 있다.

해당 필드로 인해 Team에서 Member를 객체 그래프 탐색을 통해 조회할 수 있게 된다.

@OneToMany(mappedBy = "team")

• 객체에서의 양방향 관계는 단방향인 관계가 양쪽으로 있다고 설명했다. 따라서 다대일의 반대는 일대다 이므로 OneToMany어노테이션을 사용한다.

• mappedBy 속성은 양방향 매핑일 때 사용된다.

여기서 연관관계의 주인에 대해 나온다.

객체에는 양방향 관계는 없고 단방향인 연관관계가 두개 있다는 것인데, 그렇다면 외래키도 두개여야 할 것이라는 생각이 들 것이다.

하지만 테이블 특성상 외래키는 한부분에 있고, 한 곳에서 양방향 연관관계를 맺는다.

이 때문에 JPA는 두 객체 연관관계 중 하나를 정해서 테이블의 외래키를 관리 해야 한다.

이것을 연관관계의 주인이라고 한다.

양방향 매핑의 규칙

연관관계의 주인만이 데이터베이스 연관관계와 매핑되고 외래키를 관리(등록, 수정, 삭제)를 할 수 있다.반면에 주인이 아닌 쪽은 읽기만 할 수 있다.

그래서 연관관계의 주인은 내맘대로 설정하는 것인가?

그것도 아니다. 대부분 외래키가 있는 곳이 연관관계의 주인이 된다.

왜냐하면, 그것이 더 관리하기 편하기 때문이다.

우선 페이지네이션이란, 필요한 데이터들을 페이지 별로 나타내는 것으로,

한 페이지에 수백만개에 해당하는 게시글 데이터들을 조회해 화면에 렌더링하는 경우, 클라이언트가 브라우저 혹은 모바일 기기로 이를 한 눈에 보기 어려움을 겪을 공산이 크다.

또한 클라이언트가 보지도 않을 데이터까지 DB에서 조회하여 네트워크를 통해 전달하기 때문에, 서버의 리소스가 불필요하게 낭비된다.

그래서 한 페이지에서는 N개의 데이터만 보여주고, 다음 페이지로 이동하라는 클라이언트의 추가 요청이 있을 때 마다 다음 순번의 N개의 데이터를 보여준다면 UX 및 리소스 측면의 단점을 보완할 수 있다.

그렇기에 페이지네이션 처리를 하는 것이다.

사실 무한 스크롤방식을 이용해 데이터 렌더링을 하려 했으나, 백엔드 파트에서 조금 더 공부하고자 페이지네이션 처리를 했다.

사실 이 전에 게시판을 만들어 보았을 때 페이지네이션 기능을 구현해 보았으나, 구현하기 많은 코드와 그 당시 코딩을 공부하기 초반이라 이해하지 못했다.

하지만 구글링을 하다가 Spring Data JPA를 이용해 페이지네이션 기능을 구현할 수 있는 것을 보았고, 이 방법이 나에게 맞을 것 같아 공부해 보았다.

PageController

// 메인페이지 게시글 리스트
    @GetMapping("/")
    public ResponseEntity<Page<PostEntity>> postList(Model model, @PageableDefault(page = 0,size = 20,sort = "postIndex",direction = Sort.Direction.DESC) Pageable pageable){
        // 로그인 세션 환경 설정

        Page<PostEntity> readAll = postService.readAll(pageable);

        // 게시글 최신순으로 정렬
        // 페이징 처리
        int nowPage = readAll.getPageable().getPageNumber()+1; //pageable이 갖고 있는 페이지는 0부터 시작하기 때문에
        int startPage = Math.max(nowPage -4,1);
        int endPage = Math.min(nowPage +5,readAll.getTotalPages());


        model.addAttribute("posts", readAll);
        model.addAttribute("nowPage", nowPage);
        model.addAttribute("startPage",startPage);
        model.addAttribute("endPage",endPage);



        return new ResponseEntity<>(readAll, HttpStatus.OK);
    }

Spring Data JPA 기능 중 JpaRepository가 있다.

현재 나는 이 레파지토리 인터페이스를 이용해 CRUD 및 기타 기능을 이용하고 있다.

JpaRepository의 부모 인터페이스로 PagingAndSortingRepository 에서 페이징과 소팅이라는 기능을 제공한다.

나는 이 PagingAndSortingRepository를 이용해 페이지네이션 처리를 할 것이다.

PagingAndSortingRepository를 이용하려면 Pageable이라는 인터페이스를 파라미터로 받아야 한다.

@PageableDefault

• Pageable의 기본정보를 입력할 수 있다.
• page : default 페이지
• size : 한 페이지 게시글 수
• sort : 정렬 기준 컬럼(여기에서는 글 번호 id)
• direction : 정렬 순서 (보통 게시판은 최근 글이 위로 올라와 있기 때문에 역순으로 설정함.)

받아온 파라미터를 service 부분에 넘긴다.

PostService

    // 게시글 리스트 가져오기
    // 페이징 처리
    public Page<PostEntity> readAll(Pageable pageable){
        Page<PostEntity> list = postRepository.findAll(pageable);

        return list;
    }

JpaRepository 부모 인터 페이스인 PagingAndSortingRepository를 보면 findAll메서드에 Pageable인자가 들어가 있는 것을 확인 할 수 있다.

findAll메서드로 DB에서 게시글들을 Page형태로 받아와 반환한다.

PageController

        int nowPage = readAll.getPageable().getPageNumber()+1; //pageable이 갖고 있는 페이지는 0부터 시작하기 때문에
        int startPage = Math.max(nowPage -4,1);
        int endPage = Math.min(nowPage +5,readAll.getTotalPages());


        model.addAttribute("posts", readAll);
        model.addAttribute("nowPage", nowPage);
        model.addAttribute("startPage",startPage);
        model.addAttribute("endPage",endPage);

여기서 현재 나의 페이지, 첫 페이지, 그리고 마지막 페이지를 지정해 view단으로 데이터를 넘기면 자연스럽게 페이지네이션 처리가 된다.

이렇게 메인 페이지의 게시글들을 페이징 하였지만, 또 다른 문제가 있었다.

내가 기획한 이 프로젝트는 지역별로 게시글들을 나눌 수 있게 만들어 놓았다.

따라서 메인페이지 뿐만아니라 지역별로 필터링한 게시글들도 페이징 처리를 해야했다.

사실 어떤 방식으로 시작해야 할지 잘 몰랐다.

Pageable 인자를 받으면서 해당 데이터를 필터링해 페이징 처리를 해야 하는 것이기 때문에,

service 부분에서 필터링할 데이터와 Pageable 값을 같이 보내야 했다.

그러다 이전 게시글에서 확인할 수 있는 검색기능의 Containing이 생각이 났다.

분명 PagingAndSortingRepository에서는 findAll(Pageable pageable)메서드만 가능 했지만, 내가 만들어서 사용할 수 있지 않을까? 라는 생각을 했다.

그래서 바로 실행에 옮겼다.

PageController

    // 시/도 select box만 설정했을 경우
    @GetMapping("/{postSido}")
    public ResponseEntity<Page<PostEntity>> searchSido(@PathVariable("postSido") String postSido,
                                                            @PageableDefault(page = 0,size = 20,sort = "postIndex",direction = Sort.Direction.DESC) Pageable pageable,
                                                            Model model){
        Page<PostEntity> sidoList = postService.findSido(postSido, pageable);

        // 페이징 처리
        int nowPage = sidoList.getPageable().getPageNumber()+1; //pageable이 갖고 있는 페이지는 0부터 시작하기 때문에
        int startPage = Math.max(nowPage -4,1);
        int endPage = Math.min(nowPage +5,sidoList.getTotalPages());

        model.addAttribute("sidoList", sidoList);
        model.addAttribute("nowPage", nowPage);
        model.addAttribute("startPage",startPage);
        model.addAttribute("endPage",endPage);


        return new ResponseEntity<>(sidoList, HttpStatus.OK);
    }

메인 페이지 메서드와 다른 것은 service api로 넘어갈 때 postSido를 추가로 파라미터에 넣어 보낸다는 것이다.

PostService

    // 시도 select box 찾기
    public Page<PostEntity> findSido(String postSido, Pageable pageable) {
        Page<PostEntity> sidoList = postRepository.findByPostSidoContaining(postSido, pageable);

        return sidoList;
    }

findByPostSidoContaining메서드에 Pageable 인자를 추가로 넣어 Page 타입으로 데이터를 가져오게 하였다.

Page<PostEntity> findByPostSidoContaining(String postSido, Pageable pagealbe);

이 때, 가져오는 데이터는 postSido에 postSido라는 데이터를 포함하는 데이터만 가져오도록 하였다.

그 후, 가져온 데이터를 반환하는 것이었다.

해당 테스트는 시/도 설정을 용인시로 설정한 페이지의 마지막 페이지이다. (기존 size는 20이지만 테스트를 위해 5로 변경)

보다시피 페이지에 따른 데이터들이 나왔다.

이렇게 필터링에 따른 데이터 페이징도 완성했다.

드디어 모든 기능들을 구현하였다.

이제 진짜 얼마 남지 않았다.

필터링에 따른 페이징 처리에 대해 애를 많이 썼는데, 혼자서 생각하여 문제를 해결한 것에 대해 정말 행복하고, 실력이 늘고 있구나에 대한 생각이 들었다.

남은 프로젝트도 열심히 하여 끝마치고 싶다.

대부분의 기능을 거의 다 만들어 놓아서 최근 JPA공부를 했었다.

프론트 부분도 js부분을 뺀 나머지 부분은 거의 다 완성되어 가서 다시 프로젝트를 진행하였다.

원래 게시글 제목과 내용에서의 키워드를 검색하면 해당 게시글들을 반환하도록 하려 했지만,

아직 JPA를 잘 다루지 못함 + JPQL을 잘 사용하지 못하여 우선 JpaRepository를 사용하여 검색 기능을 만들기로 하였다.

검색 기능은 프로젝트가 끝나기 전까지 JPA를 이용해서 검색기능을 리펙토링 하던지, JpaRepository를 이용해서 게시글 내용에서도 키워드를 찾을 수 있도록 하던지 할 예정이다.

PageController

    @GetMapping("/post/search")
    public ResponseEntity<List<PostEntity>> search(@RequestParam("keyword") String keyword, Model model){
        List<PostEntity> searchList = postService.search(keyword);
        model.addAttribute("searchList", searchList);

        return new ResponseEntity<>(searchList, HttpStatus.OK);
    }

HTML에서의 input 태그로 해당 키워드를 가져오도록 만들었다.

키워드는 RequestParam 어노테이션으로 가져온다.

가져온 키워드를 postService의 search 메서드로 넘겨 해당 키워드를 가진 제목의 게시글들을 가져온다.

PostService

    public List<PostEntity> search(String keyword) {

        List<PostEntity> search = postRepository.findByTitleContaining(keyword);
        List<PostEntity> searchList = new ArrayList<>();

        if(search.isEmpty()) return search;

        for(PostEntity post : search) {
            searchList.add(post);
        }
        return searchList;
    }   

해당 키워드를 postRepository의 findByTitleContaining이라는 메서드로 보낸다.

사실 여기서 가장 중요한 부분은 postRepository의 메서드라고 생각한다.

@Repository
public interface PostRepository extends JpaRepository<PostEntity, Long>{
    List<PostEntity> findByTitleContaining(String keyword);
}

기본적으로 JpaRepository에서 메소드명의 By 이후는 SQL의 where 조건 절에 대응된다.

findByTitleContaining은 title에서 들어있는 내용을 찾는 Like검색과 동일하다고 생각하면 된다.

가져온 PostEntity를 for문을 이용해 추가한 뒤, 반환한다.

검색 기능에 대해 postman으로 테스트를 진행하려는데 문제가 발생했다.

키워드라는 파라미터가 존재하지 않는다는 오류가 나왔다.

분명 다른 메서드들과 똑같이 RequestParam을 사용해서 form 태그로 데이터를 보냈는데도, 계속 오류가 났다.

그래서 오타가 있는지도 오랬동안 확인해 보았지만, 오타는 없고, 계속 오류가 났다.

한참동안 이 문제를 가지고 고전했다.

분명 다른 메서드와 다른건 매핑 방법(Get, Post)밖에 없는데 왜 안되는 거지 라는 생각을 했다.

근데 문득 공부한 것이 생각이 났다.

서버로 데이터를 보내는 방법중 Get방식으로 쿼리 파라미터를 보내는 것과, Post방식으로 form태그를 이용해 보내는 방법이 있다는 것이 기억이 났다.

그래서 내가 velog에 복습 겸 써놓았던 것들을 확인했다.

https://velog.io/@yoon_bly/%EC%8A%A4%ED%94%84%EB%A7%81-MVC-1%ED%8E%B8-%EB%B0%B1%EC%97%94%EB%93%9C-%EC%9B%B9-%EA%B0%9C%EB%B0%9C-%ED%95%B5%EC%8B%AC-%EA%B8%B0%EC%88%A0%EC%84%9C%EB%B8%94%EB%A6%BF#%EC%A4%91%EC%9A%943-http-%EC%9A%94%EC%B2%AD-%EB%8D%B0%EC%9D%B4%ED%84%B0---%EA%B0%9C%EC%9A%94

이 게시글에서 데이터 요청 방법을 내가 복습해 놓았던 것이다.

GetMapping으로 파라미터를 보내는 방법은 url 뒤에 파라미터로 보내는 것이고, PostMapping으로 파라미터를 보낼 때는 form태그를 이용해 HTTP Body에 파라미터를 넣어 보내는 것이다.

그래서 url뒤에 파라미터를 넣어서 테스트 해보았다.

사진에서 보다시피 url뒤에 "?keyword=가나다"라는 파라미터를 넣어서 데이터를 보냈더니 정상적으로 데이터가 보내져 "가나다"라는 keyword를 가진 게시글을 정상적으로 받아왔다.

다행히도 해당 문제를 해결해서 다행이다.

오늘은 내가 여태까지 공부했던 것들을 복습해 둔것을 정말 다행이라고 생각하고 장하다고 생각된 하루였다.

만약 내가 공부한 것을 복습해두지 않았더라면 오늘 이 문제에 더 많은 시간을 투자했을 것이다.

이렇게 다시한번 복습이 얼마나 중요한지 알게 되었던 하루였다.

물론 복습을 했지만, 기억을 못한 나에게 조금 실망스러웠지만, 그래도 복습을 했기 때문에 시간을 별로 쓰지 않았다고 생각한다.

앞으로 남은 프로젝트 일들도 빠르게 마무리 하여서 완성된 페이지를 얼른 만들어 보고 싶다.

서비스를 배포했을 때, 코드들의 진행에 따라 테스트를 해보았다.

예를 들면,

1) 회원 가입 -> 로그인 -> 게시글 작성

2) 여러 사용자들이 게시글 여러개 작성 -> 시/군/동 select box에 따른 게시글 필터링 -> 내 게시글 페이지

3) 로그인 -> 댓글 작성 -> 수정 및 삭제

등등 여러가지 상황을 고려해 사용자가 해당 서비스를 이용할 때 진행되는 구조에 대한 테스트를 진행해보았다.

결과는 모두 성공.

내가 원하는 대로 결과 값들이 나왔다.

대부분의 기능들을 완성하고 오늘처럼 테스트를 하고나니, 정말 내가 무언가 만들었다는 생각에 기분이 좋아졌다.

이런 성취감이 드는 일이 있을 때마다, 내가 이 개발 공부를 하는 것을 잘했다고 생각하게 된다.

아직 게시글 검색 기능, 프론트 작업을 마친 후 프론트단에 따른 백엔드 코드 수정, 리턴값 변경, 프론트단과 백단간의 데이터 통신 작업, 성능 최적화 등등 할일이 많다.

하지만 걱정이 들지는 않다.

이미 이 프로젝트에 대한 애정이 깊어져 어떻게든 완성을 하겠다는 생각이 계속 든다.

앞으로 다른 프로젝트도 진행하게 될 것이고, 공부도 더 열심히 해서 내가 개발에 대한 이해도가 높아지면 리펙토링을 통해 업데이트도 진행 할 것이다.

그렇기엔 이 공부를 포기하지 않을 것이다.

별로 길지 않은 인생을 살았지만, 이 정도로 공부가 재밌는 것이 처음이다.

얼른 더 많은 것을 배우고 싶다.

그렇기에 더욱 열심히 하고, 열심히 복습해야겠다.

가장 먼저 댓글이 보여지는 화면은 게시글 상세페이지에 들어가면 보이기 때문에 postController에 replyService 메서드를 기입했다.

PostController

    // 게시글 상세보기
    @GetMapping("/post/{postId}")
    public ResponseEntity<Integer> read(HttpSession session, @PathVariable(name = "postId") Long postId, Model model) {
        Long userIndex = (Long) session.getAttribute("userIndex");

        // 게시글 model
        Optional<PostEntity> post = postService.read(postId);
        model.addAttribute("post", post);

        // 댓글 model
        List<ReplyEntity> replyList = replyService.read(postId);
        model.addAttribute("reply", replyList);


        // 세션을 가져와서 만약 게시글, 댓글 userIndex와 같다면, 1을 출력해 수정 및 삭제 버튼 활성화 / 다르면 0 or 2 출력
        // 수정 필요
        Integer checkedUserIndex = 0;
        if(userIndex != null){
            if(userIndex == post.get().getUserIndex()){
                // 게시글, 댓글, 세션이 같으면
                checkedUserIndex = 1;
                model.addAttribute("checkIndex", checkedUserIndex);
            } else if(userIndex != post.get().getUserIndex()){
                checkedUserIndex = 2;
                model.addAttribute("checkIndex", checkedUserIndex);
            } else {
                model.addAttribute("checkIndex", checkedUserIndex);
            }
        }


        return new ResponseEntity<>(checkedUserIndex, HttpStatus.OK);
        // return "post_detail";
    }

해당 게시글의 index를 가져와서 댓글들을 가져오게 만들었다.

여기서 댓글도 만약 로그인한 유저가 단 댓글일 때, 수정 및 삭제 버튼이 생성되어야 한다.

만약 게시글 userIndex가 같다면, 게시글이 자신의 것이기 때문에 댓글도 자신의 것일 것이다.

그래서 댓글에 대한 수정 및 삭제 버튼도 게시글 수정 및 삭제 버튼과 같이 조건문으로 값을 가져와 버튼 display를 활성화/비활성화 시키면 된다.

ReplyService

@Service
public class ReplyService {

    @Autowired
    private ReplyRepository replyRepository;

    // 댓글 저장
    @Transactional
    public ReplyEntity save(ReplyDto replyDto, Long userIndex, Long postIndex) {
        ReplyEntity replyEntity = replyDto.toEntity(userIndex, postIndex);

        replyRepository.save(replyEntity);

        return replyEntity;
    }

    // 게시글 읽어올 때 해당 게시글 댓글 불러오기
    public List<ReplyEntity> read(Long postIndex) {
        List<ReplyEntity> replyList = replyRepository.findByReplyPostIndex(postIndex);

        return replyList;
    }

    // 댓글 수정
    @Transactional
    public Optional<ReplyEntity> edit(Long replyIndex, ReplyDto replyDto) {
        Optional<ReplyEntity> reply = replyRepository.findById(replyIndex);

        return reply.map(r -> {
            reply.get().setReplyDescription(replyDto.getReplyDescription());

            return r;
        })

            .map(r -> replyRepository.save(r));
    }

    // 댓글 삭제
    public void delete(Long replyIndex) {
        replyRepository.deleteById(replyIndex);
    }
}

해당 메서드들은 게시글 메서드와 거의 비슷한 형태를 띄고있다.

이제 백엔드는 거의 마무리 단계에 돌입했다.

이제 내가 짠 코드를 검토해보고, 메모리 최적화, return 값 변경, thymeleaf 설정등이 남았다.

아직 성능 최적화, 메모리 최적화를 해본적이 없어서 좀 더 구글링 해보고 찾아봐야한다.

아직 프로젝트가 완성된 것은 아니지만, 무언가 내가 생각해낸 것을 만들어 냈다는 생각에 기분이 좋아진다.

아직 부족한 부분이 많지만, 좀 더 성능 개선에 힘쓰고, 공부를 더 해야겠다.

얼른 프론트 부분이 마무리 지어져 내가 만든 것들을 postman이 아닌 화면으로 테스트 해보고 싶다.

얼마 안남은 프로젝트 확실하게 마무리 하고 싶은 마음이 더 커지는 것 같다.

이전의 회고록 마지막 부분에 써놨던, 해당 게시글이 로그인한 유저의 게시글인지 확인하는 방법에 대하여 고민하고 코드를 작성해보았다.

해당 고민은 자신의 게시글일 경우 수정 및 삭제를 할 수 있도록 해야하므로 수정 및 삭제 버튼을 활성화/ 비활성화 시킬 방법을 모색한 것이다.

로그인 부분을 혼자 공부하기도 했고, 기능구현도 처음이다 보니 이게 정확한 방법, 제대로된 방법은 아닐 것이다.

하지만, 나만의 생각으로 고민하고, 기능을 구현하는 것은 분명 나중에 도움이 될것이라고 생각된다.

로그인한 유저의 게시글인지 확인하려면 필요한 것은 로그인한 유저의 세션에 저장된 userIndex와 게시글의 userIndex가 같은지 확인하면 된다.

만약 두 userIndex가 같다면 자신의 글인 것이니까.

postController를 보면 해당 게시글을 찾아 View단으로 뿌리는 로직이다.

    // 게시글 상세보기
    @GetMapping("/post/{postId}")
    public ResponseEntity<Integer> read(HttpSession session, @PathVariable(name = "postId") Long postId) {

        Optional<PostEntity> post = postService.read(postId);
        model.addAttribute("post", post);

        return new ResponseEntity<>(post, HttpStatus.OK);
        // return "post_detail";
    }

해당 url로 데이터를 보내려면 우선 게시글 정보는 필수로 view단에 넘겨야 한다.

그래서 나는 생각했다.

이름이 다른 model을 생성해서 하나는 게시글 정보를, 다른 하나는 로그인 세션userIndex가 게시글 userIndex와 같은지 체크하는 정보를.

그래서 혹시 model 값을 js로 가져와 index가 같으면 버튼 display를 활성화 시키고 index가 다르면 display를 비활성화 시킬수 있나 라는 생각을 하게 되었고, 구글링을 해보았다.

https://mollangpiu.tistory.com/331

해당 게시물을 보면 타임리프로 받아온 데이터를 js에서도 사용할 수 있는 것을 확인하였고, 바로 로직을 구현해 보았다.

    // 게시글 상세보기
    @GetMapping("/post/{postId}")
    public ResponseEntity<Integer> read(HttpSession session, @PathVariable(name = "postId") Long postId, Model model) {
        Long userIndex = (Long) session.getAttribute("userIndex");

        Optional<PostEntity> post = postService.read(postId);
        model.addAttribute("post", post);


        // 세션을 가져와서 만약 게시글 userIndex와 같다면, 1을 출력해 수정 및 삭제 버튼 활성화
        Integer checkedUserIndex = 0;
        if(userIndex != null){
            if(userIndex == post.get().getUserIndex()){
                model.addAttribute("correct", "1");
                checkedUserIndex = 1;
            } else if(userIndex != post.get().getUserIndex()){
                model.addAttribute("incorrect", "0");
                checkedUserIndex = 2;
            }
        }

        return new ResponseEntity<>(checkedUserIndex, HttpStatus.OK);
        // return "post_detail";
    }

해당 로직을 보면, 우선 세션을 통해 로그인한 유저의 index를 가져온다.

그리고, 게시글의 userIndex를 가지고 올 수 있도록 먼저 게시글을 찾아온다.

그 후, 사용자 userIndex와 게시글 userIndex가 같으면 1, 다르면 2, 로그인이 되어있지 않은 상태에서 게시글을 보게되면 0을 출력하게 만들었다.

나의 생각은 이렇다.

model로 받은 게시글 데이터는 바로 보여주고, 자신의 게시글인지 체크하는 model은 js로 받아 0,2를 받아오면 수정 및 삭제 버튼 비활성화, 1을 받아오면 수정 및 삭제 버튼 활성화

이렇게 만들어보았다.

이 이후의 수정 페이지 들어가는 로직, 수정 로직, 삭제 로직은 방금 설명한 상세 게시글 들어갈 때 이미 자신의 게시글인지 확인할 수 있기 때문에 자신의 게시글인지 체크할 이유는 없을 것 같다.

혼자 공부하면서 이렇게 내가 혼자 생각해서 만드는 로직이 참 재미있는 것 같다.

뭔가 내가 직접 만들었다는 생각이 드니 기분이 좋아진다.

이런 경험도 성장하는데 일부분을 차지하는 것 일지는 모르겠지만, 이렇게 계속 꾸준히 공부하고, 생각하면 언젠간 도움이 될거라 생각한다.

또, 회원가입 시 아이디 및 닉네임 중복 체크 버튼 없이 중복 체크를 하는 방법에 대해 찾아보았다.

jpa를 잘 다루지 못하는 나이기에 postEntity에 userIndex를 추가하여 해당 게시글이 사용자의 게시글인 것을 알 수 있게 해야했다.

그래서 가장 먼저 PostEntity를 수정하였다.

엔티티 수정

@Entity(name = "post")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Table
public class PostEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long postIndex;

    @Column(length = 1000)
    @NotNull
    private String title;

    @Column(length = 1000)
    @NotNull
    private String description;

    @CreationTimestamp //INSERT 쿼리가 발생할 때, 현재 시간을 값으로 채워서 쿼리를 생성한다.
    @Column
    private LocalDateTime postRegDate;

    @Column(length = 1000)
    @NotNull
    private String postSido;

    @Column(length = 1000)
    @NotNull
    private String postGugun;

    @Column(length = 1000)
    @NotNull
    private String postDong;

    @Column(length = 1000)
    private String postLanguage1;

    @Column
    private String postLanguage2;

    @Column
    private String postLanguage3;

    // 유저 인덱스
    @Column
    @NotNull
    private Long userIndex;

    public PostDto toDto() {
        PostDto postDto = PostDto.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postDto;
    }
}

이전의 PostEntity와 다른 점은 사용언어인 postLanguage를 3개로 늘렸다.

원래는 하나의 postLanguage 컬럼을 만들어 여러 데이터를 집어 넣으려했지만, 방법도 모르겠고, 찾아보니 관계형 DB에서는 한 컬럼에 여러 데이터를 넣는 것은 좋지 않다는 것을 알게 되었다.

그래서 그냥 컬럼을 여러개 만들고 Null이어도 되게 만들었다.

또한 userIndex를 컬럼으로 가져왔다.

게시글 작성 수정

Controller

다음으로 Controller의 게시글 작성 메서드를 수정하였다.

게시글을 쓰기 위해선 로그인이 필수이다.

하지만 로그인이 안되어있는 상태에서는 게시글 작성 url을 html에 넣어두지 않을 것이기 때문에, 로그인 체크를 따로 안해도 된다.

    @PostMapping("/post/save")
    public ResponseEntity<PostEntity> save(HttpSession session, @ModelAttribute("post") PostDto postDto){
        Long userIndex = (Long) session.getAttribute("userIndex");
        PostEntity post = postService.save(postDto, userIndex);    // 변경해야함( 테스트위해서 변경 )
        // postService.save(postDto, userIndex);

        return new ResponseEntity<>(post, HttpStatus.OK);
        // return "redirect:/post_detail.html";
    }

Long userIndex = (Long) Session.getAttribute("userIndex");

가장 먼저 게시글 저장 버튼을 누르려면 기본적으로 로그인 세션이 있는 상태일 것이다.

그래서 세션에서 사용자의 index를 가져온다.

PostEntity post = postService.save(postDto, userIndex);

그후 postService의 save 메서드로 작성된 게시글 정보와 userIndex를 파라미터로 넘긴다.

service

    public PostEntity save(PostDto postDto, Long userIndex) {
        PostEntity postEntity = postDto.toEntity(userIndex);
        PostEntity saved = postRepository.save(postEntity);

        return saved;
    }

파라미터로 받아온 postDto와 userIndex를 저장해야한다.

하지만 여기서 문제는 postDto와 userIndex는 따로 데이터가 온다는 것이다.

게시글을 userIndex를 추가해 저장하기 위해서는 userIndex를 postEntity에 추가해 저장해야 한다.

그래서 혼자 생각을 해보았다.

controller에서 service로 넘어갈때 Dto로 넘어가는데 repository에서는 해당 dto를 entity로 변경해 저장해야 한다.

그러면 dto에서 entity로 넘어갈 때 userIndex를 추가할 수는 없는건가라는 생각을 했다.

여기서 dto와 entity를 따로두는 이유는 모두가 알 것이다.

DTO와 Entity를 분리하는 이유

DTO(Data Transfer Object)는 Entity 객체와 달리 각 계층끼리 주고받는 우편물이나 상자의 개념입니다. 순수하게 데이터를 담고 있다는 점에서 Entity 객체와 유사하지만, 목적 자체가 전달이므로 읽고, 쓰는 것이 모두 가능하고, 일회성으로 사용되는 성격이 강합니다.

그래서 dto를 entity로, entity를 dto로 변경하는 메서드가 필요하다.

PostEntity

public PostDto toDto() {
        PostDto postDto = PostDto.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postDto;
    }

PostDto

public PostEntity toEntity() {
        PostEntity postEntity = PostEntity.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postEntity;
    }

만약 dto에서 entity로 변경할 때 파라미터로 userIndex를 넣으면 해당 userIndex를 엔티티에 추가할 수 있지 않을까 라는 생각으로 toEntity 메서드를 수정해보았다.

public PostEntity toEntity(Long userIndex) {
        PostEntity postEntity = PostEntity.builder()
        .title(title)
        .description(description)
        .postRegDate(postRegDate)
        .postSido(postSido)
        .postGugun(postGugun)
        .postDong(postDong)
        .postLanguage1(postLanguage1)
        .postLanguage2(postLanguage2)
        .postLanguage3(postLanguage3)
        .userIndex(userIndex)
        .build();

        return postEntity;
    }

toEntity메서드를 수정한 후, 서버를 돌려 postman으로 테스트를 돌려보았는데, userIndex가 잘 들어가있는 것을 확인할 수 있었다.

아이디 및 닉네임 중복 체크

이미 아이디 및 닉네임의 중복 체크 기능은 구현해두었다.

하지만 프론트 디자인 중, 회원가입 페이지에서 중복 체크 버튼이 없는 것이 더 디자인이 괜찮다는 얘기가 나와, 중복 체크 버튼 없이 중복 체크를 할 수 있는지 찾아보았다.

https://kimvampa.tistory.com/90

구글링 중 해당 페이지에서 해답을 찾을 수 있었다.

propertychange change keyup paste input

해당 js 기능은 html의 input 태그의 값을 실시간으로 처리할 수 있도록 하는 기능이다.

이 기능을 사용해서 ajax로 input 값을 보내 해당 아이디나 닉네임을 중복체크를 하게 한다.

만약 중복이라면 1을, 사용가능한 아이디나 닉네임이면 0을 반환해 사용가능을 확인하게 한다.

오늘은 생각보다 중요한 작업을 한것 같다.

확실히 로그인 구현은 여러가지를 생각하게 한다.

아직 중요한 작업들이 많이 남았다.

공부하다 생각한 것인데, 자기가 작성한 게시글이면 수정 및 삭제 버튼이 있어야하고, 자기가 작성한 게시글이 아니라면, 수정 및 삭제 버튼이 없어야 한다.

해당 게시글이 자신이 작성한 게시글인지 아닌지를 어떻게 판단해야 하는가에 대한 고민이었다.

이 고민은 차차 생각해봐야겠다.

사실 TDD 방식으로 백엔드 작업을 진행하여 공부했던 CRUD까지는 테스트가 가능했지만, 로그인 기능 구현, 이미지 파일 저장 기능 구현 등 모르는 것을 배우려다보니 TDD 방식으로 하기 까다로웠다.

그래서 코드를 작성하면서 그때 그때 postman으로 테스트를 진행하는 방식으로 하였다.

사실 아직 공부를 많이 하지 못한 나의 잘못이라고 판단이 된다. 앞으로 공부를 더 열심히 해야겠다는 생각이 코드를 작성하면서 느꼈다.

전날 했던 회원 정보 수정 기능에 대해 postman으로 테스트했다.

진행 순서

개인정보를 수정하기 위해서는 회원정보가 필요하여 회원가입이 먼저 필요했고, 프로필을 저장하기 위해서는 로그인이 필요하다.

그래서 테스트 진행 순서는 이전에 만들었던 회원가입 로직, 그 다음 로그인을 한 후 회원 정보를 수정하는 순서로 진행 하였다.

회원가입 -> 로그인 -> 회원정보 수정

회원가입

Controller

    @PostMapping("/signup")
    public ResponseEntity<UserEntity> signup(UserDto userDto){
        UserEntity user = userService.save(userDto);

        return new ResponseEntity<>(user, HttpStatus.OK);
    }

Service

    public UserEntity save(UserDto userDto) {
        UserEntity entity = userDto.toEntity();
        userRepository.save(entity);

        return entity;
    }

회원 가입에 필요한 데이터들을 form태그를 이용해 데이터를 보낼것이기 때문에 x-www-form-urlencoded 방식으로 데이터를 기입해 보냈다.

반환값은 ResponseEntity를 이용하여 테스트 하였다.

회원가입 완성!

로그인

Controller

    @PostMapping("/login")
    public ResponseEntity<String> login(@RequestParam("userId") String userId,@RequestParam("userPassword") String userPassword, HttpSession session){
        Long userIndex = userService.login(userId, userPassword);
        if(userIndex == null){
            return new ResponseEntity<>("no userData", HttpStatus.BAD_REQUEST);
            // return "redirect:/login";
        }
        session.setAttribute("userIndex", userIndex);
        log.info(session.getAttribute("userIndex").toString());

        return new ResponseEntity<>(userIndex.toString(), HttpStatus.OK);
        // return "redirect:/";
    }

사용자의 아이디와 비밀번호를 받아와 로그인을 한다.

반환값으로 해당 아이디 비밀번호로 로그인 했을 때 세션을 저장하고, 해당 사용자의 index를 반환했다.

지금 회원정보는 1명이기 때문에 1을 반환한다.

회원정보 수정(문제 및 해결)

오늘의 가장 메인 파트이다.

사실 저번에 썼던 코드로 테스트를 진행해 보았는데 파일이 저장이 안되고, 프로필 엔티티도 생성되지 않았다.

맨 처음 테스트를 진행했을 때, 엔티티는 생성되었지만, 파일이 로컬 컴퓨터에 저장이 안되는 것으로 알았다.

그래서 파일 경로를 찾아 보았다.

찾아보던 와중 생각해보니

    public Optional<ProfileEntity> storeFile(MultipartFile multipartFile, Long userIndex) throws IOException {
        if(multipartFile.isEmpty()){
            return null;
        }

        String originFileName = multipartFile.getOriginalFilename();
        String storeFileName = createStoreFileName(originFileName);
        multipartFile.transferTo(new File(getFullPath(storeFileName)));

        ProfileEntity entity = ProfileEntity.builder()
                                    .originFileName(originFileName)
                                    .storeFileName(storeFileName)
                                    .userIndex(userIndex)
                                    .build();

        Optional<ProfileEntity> profileEntity = profileRepository.findByUserIndex(userIndex);

        // 만약 유저 인덱스를 가진 프로필엔티티가 있으면 해당 프로필 엔티티를 수정
        if(profileEntity != null){
            profileEntity.map(p -> {
                profileEntity.get().setOriginFileName(originFileName);
                profileEntity.get().setStoreFileName(storeFileName);
                profileEntity.get().setUserIndex(userIndex);

                return p;
            })
            .map(p -> profileRepository.save(p));

            return profileEntity;
        }
        // 없다면 프로필 엔티티를 생성해서 저장
        else{
            ProfileEntity saved = profileRepository.save(entity);
            Optional<ProfileEntity> find =profileRepository.findById(userIndex);
            return find;
        }
    }

profileEntity는 Optional로 감싼 타입인데, if문에 null값을 넣어 조건문을 만들었던 것이다.

그래서 테스트를 해보며 DB를 확인 했는데 역시나 생성되어있지도 않았다.(애초에 조건문이 성립되지 않았기 때문에 else문도 안되었다.)

    public Optional<ProfileEntity> storeFile(MultipartFile multipartFile, Long userIndex) throws IOException {
        if(multipartFile.isEmpty()){
            return null;
        }

        String originFileName = multipartFile.getOriginalFilename();
        String storeFileName = createStoreFileName(originFileName);

        try{
            multipartFile.transferTo(new File(getFullPath(storeFileName)));
        }catch(Exception e){
            System.out.println("can't upload file");
        }

        ProfileEntity entity = ProfileEntity.builder()
                                    .originFileName(originFileName)
                                    .storeFileName(storeFileName)
                                    .userIndex(userIndex)
                                    .build();

        Optional<ProfileEntity> profileEntity = profileRepository.findByUserIndex(userIndex);

        // 만약 유저 인덱스를 가진 프로필엔티티가 있으면 해당 프로필 엔티티를 수정
        if(!profileEntity.isEmpty()){
            profileEntity.map(p -> {
                profileEntity.get().setOriginFileName(originFileName);
                profileEntity.get().setStoreFileName(storeFileName);
                profileEntity.get().setUserIndex(userIndex);

                return p;
            })
            .map(p -> profileRepository.save(p));

            return profileEntity;
        }
        // 없다면 프로필 엔티티를 생성해서 저장
        else{
            profileRepository.save(entity);
            Optional<ProfileEntity> find =profileRepository.findById(userIndex);
            return find;
        }
    }

그래서 if문을 isEmpty 메서드를 사용하여 "비어있지 않다면" 이라는 조건으로 변경하였다.

변경 후 테스트를 돌려보니 해당 엔티티는 생성이 되었다.

하지만 여전히 파일이 저장은 안되었다.

그래서 FileStore클래스의 모든 코드를 확인해보았다.

하지만 모두 맞는 코드였다.

결국 경로 설정이 잘못되었던 것인가라는 결론이 나왔다.

properties로 경로를 설정하려 했는데 구글에도 잘 나오지 않았던 터라 일단 넘어갔었다.

그래서 구글링을 해본 결과

    // 파일 경로
    @Value("${file.dir}")
    private String fileDir;

경로설정을 위한 어노테이션인 @Value를 사용하기 위해 properties에서 경로를 지정해주어야한다.

나는 file.dir이라는 이름으로 주소를 설정할 것이기 때문에 properties에

file.dir = 파일을 저장할 폴더 위치

이런 식으로 설정을 해야한다.

하지만 주소를 설정할 때 주의해야 할 점은 주소 마지막에 / 를 넣어줘야 한다는 점이다.

그래서 나는 주소를 넣은 뒤에 테스트를 돌려보았다.

file.dir = file.dir = C:\Users\yhw01\talkcoding\src\main\resources\static\upload\

하지만 갑자기 잘되던 서버가 오류가 나버렸다.

... 갑자기 오류가 나서 멘붕이 왔다.

인코딩이 잘못되었다는 오류인것 같아서 고민을 해보다 파일 저장 경로 이름이

이 슬래시로 되어있어서 설마하고 반대 슬래시로 고친 후 돌려보았더니 해결이 되었다.

정말 다행이었다.

이렇게 하고 테스트를 진행해 보았다.

결국 엔티티는 생성이 되었고 내가 원하는 파일도 저장이 된 것을 확인할 수 있었다.

오늘 나는 이 이미지 저장 기능의 구현을 끝마쳐서 너무 행복하다.

오랫동안 고민하며 공부했던 것이기에 성공할 수 있어서 정말 뿌듯한 하루였던 것 같다.

앞으로도 더욱 열심히 해서 프로젝트를 성공적으로 마무리 해야겠다.

내일의 나도 파이팅 하자!!

엔티티

사용자는 하나의 프로필을 설정할 수 있기 때문에 1대1관계라 생각하고 ProfileEntity를 따로 하나 더 생성하였다.

ProfileEntity

public class ProfileEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long profileIndex;

    @Column
    private Long userIndex;

    @Column
    private String originFileName;

    @Column
    private String storeFileName;

    public ProfileDto toDto(){
        ProfileDto profileDto = ProfileDto.builder()
        .userIndex(userIndex)
        .originFileName(originFileName)
        .storeFileName(storeFileName)
        .build();

        return profileDto;
    }
}

private String originFileName;

• 사용자가 업로드한 원본 이름

private String storeFileName;

• 업로드된 파일의 이름이 겹칠 수 있기 때문에 저장한 파일 이름을 다르게 했다.

private Long userIndex;

• 사용자 인덱스의 FK

FileStore Class

파일을 저장하는데 있어서 특화된 메소드들을 따로 클래스로 구성하여 이를 분리해두었다.

FileStore

public class FileStore {

    @Autowired
    private ProfileRepository profileRepository;

    // 파일 경로
    @Value("${file.dir}")
    private String fileDir;

    // 파일 경로 구성
    public String getFullPath(String storeFileName) {
        return fileDir + storeFileName;
    }

    // 프로필을 저장 -  이미 유저인덱스로 찾아 엔티티가 있을 경우 수정 / 없으면 저장
    public Optional<ProfileEntity> storeFile(MultipartFile multipartFile, Long userIndex) throws IOException {
        if(multipartFile.isEmpty()){
            return null;
        }

        String originFileName = multipartFile.getOriginalFilename();
        String storeFileName = createStoreFileName(originFileName);
        multipartFile.transferTo(new File(getFullPath(storeFileName)));

        ProfileEntity entity = ProfileEntity.builder()
                                    .originFileName(originFileName)
                                    .storeFileName(storeFileName)
                                    .userIndex(userIndex)
                                    .build();

        Optional<ProfileEntity> profileEntity = profileRepository.findByUserIndex(userIndex);

        // 만약 유저 인덱스를 가진 프로필엔티티가 있으면 해당 프로필 엔티티를 수정
        if(profileEntity != null){
            profileEntity.map(p -> {
                profileEntity.get().setOriginFileName(originFileName);
                profileEntity.get().setStoreFileName(storeFileName);
                profileEntity.get().setUserIndex(userIndex);

                return p;
            })
            .map(p -> profileRepository.save(p));

            return profileEntity;
        }
        // 없다면 프로필 엔티티를 생성해서 저장
        else{
            ProfileEntity saved = profileRepository.save(entity);
            Optional<ProfileEntity> find =profileRepository.findById(userIndex);
            return find;
        }
    }

    // storeFile 이름 구성
    private String createStoreFileName(String originFileName) {
        String uuid = UUID.randomUUID().toString();
        String ext = extractExt(originFileName);
        String storeFileName = uuid + ext;

        return storeFileName;
    }

    // 확장자 추출
    private String extractExt(String originFileName) {
        int idx = originFileName.lastIndexOf(".");
        String ext = originFileName.substring(idx);
        return ext;
    }
}

@Value("${file.dir}") private String fileDir;

• 파일을 실제로 저장해둘 경로를 지정

private String extractExt(String originFileName){...}

• 파일의 확장자를 추출하는 메서드

private String createStoreFileName(String originFileName) {...}

• 저장할 파일 이름 구성
• UUID를 통해 동일한 파일이름 저장 방지

public String getFullPath(String storeFileName) {...}

• storeFileName에 들어갈 파일 경로 구성

public Optional<ProfileEntity> storeFile(MultipartFile multipartFile, Long userIndex) throws IOException {...}

• 원본 파일 이름과 저장할 파일 이름을 반환하게 해주는 메서드

이 storeFile 메서드가 가장 중요한 부분이다.

파일을 저장시켜주는 메서드로써, originFileName과 storeFileName의 값을 반환해야 한다.

파라미터를 multipartFile과 회원정보를 수정하고 있는 유저의 인덱스를 받아와

multipartFile들을 String타입으로 변환 후 새로운 ProfileEntity를 생성한다.

하지만, 프로필은 하나만 있어야 하므로, 만약 동일한 userIndex를 갖고 있는 ProfileEntity가 있는 경우 해당 Entity에 덮어씌우게 하고, 동일한 userIndex가 없다면 Entity를 생성하는 방식으로 만들었다.

컨트롤러

프로필 변경 작업은 회원정보 변경 페이지에서 진행되기 때문에 UserController에 로직을 생성하였다.

이전에 프로필이 아닌 이름, 닉네임, 전화번호를 변경하는 로직에 프로필 변경 로직을 추가하였다.

    // 회원정보 수정 버튼 기능
    @PostMapping("/user/edit")
    public ResponseEntity<Optional<UserEntity>> userEdit(HttpSession session,@RequestParam("originFileName") MultipartFile originFileName, @ModelAttribute UserDto userDto) throws IOException{
        Long userIndex = (Long) session.getAttribute("userIndex");

        UserEntity user = userDto.toEntity();

        // 회원 정보 수정
        Optional<UserEntity> userInfo = userService.changeUserInfo(userIndex, user);

        // 프로필 수정
        profileService.saveProfile(originFileName, userIndex);

        return new ResponseEntity<>(userInfo, HttpStatus.OK);
    }

Optional<UserEntity> userInfo = userService.changeUserInfo(userIndex, user);

• 해당 페이지의 세션을 받아와 사용자의 userIndex를 받아오고, 수정된 이름, 닉네임, 전화번호를 dto로 받아와 수정시켜준다.

여기까지는 이전에 있던 로직이다.

profileService.saveProfile(originFileName, userIndex);

• 프로필이 변경된 파일을 MultipartFile로 받아와 회원정보 수정 메서드와 같이 userIndex와 함께 서비스 부분으로 넘겨준다.

서비스

    public ProfileEntity saveProfile(MultipartFile originFileName, Long userIndex) throws IOException {
        fileStore.storeFile(originFileName, userIndex);
        return null;
    }

컨트롤러에서 받아온 파일과 userIndex를 StoreFile메서드로 넘겨 ProfileEntity를 생성하고, 파일을 저장한다.

아직 로직을 전부 만들지는 않았지만, 파일과 이미지 업로드 기능에 대하여 여러가지 공부를 하였다.

이 이미지 저장 로직에 대해 이해가 잘 안되었어서 오래걸리긴 했지만, 혼자 공부하는 것 치고 꽤 빠르게 이해한 것 같다.

또 이렇게 기술 회고를 작성하며 복습할 수 있어서 참 다행인것 같다.

만약 복습을 하지 않았다면, 이 프로젝트가 끝난 뒤에 나중에 또 이미지 파일을 저장할 때 다시 공부를 해야겠지만, 복습을 통해서 완전히 나의 것으로 만들었다.

오늘은 안풀리던 이미지 저장 로직을 이해해서 참 기분 좋았다.

앞으로 남은 로직과 프론트와의 데이터 렌더링을 잘 마무리 하고, 프로젝트를 성공적으로 끝낼 수 있었으면 좋겠다.