Spring Data JPA Dependency 추가 : 포함된 dependency -JDBC, JPA, hibernate(jpa 구현체), AOP 왜 포함되어있을까? aop를 왜 포함하고 있을까?

• GlobalException처리->@RestControllerAdvice - AOP연결
• @Transactional-> 트랜잭션이 시작/끝을 알리기위해 앞뒤로 붙어야 함 스프링이 어노테이션을 달아놓으면 자동으로 해줌.
• DI, IOC, AOP 스프링만 가지고 있는 것이아니라, 좋은 걸 골라다가 만들어 놓은 프레임워크

왜 aop가 필요할까?

AOP (Aspect Oriented programming: 관점지향 프로그래밍)

• 관점 지향 프로그래밍 1) 구매 개발자: 구매 버튼 클릭 > ✔️ ~> 구매 완료 2) 장바구니 개발자: 장바구니 버튼 클릭 > ✔️ ~> 아이템 삭제 완료 3) 찜하기: 장바구니 버튼 클릭 > ✔️ ~> 찜하기 로직 4) 로그인 체크 개발자: ** 로그인 체크**✔️

  각각 다들 개발하려는 관심은 다르지만, 구매를 클릭했을 때 로그인이 여부를 체크하는 로직은 동일함. => 세로 관점을 봤을 때, 로그인 체크로직이 공통적임 새로운 관점으로 개발할게~! 필요할때 갖다 쓰기만 하면 됑!

  @Before: 시점을 찍어놓는 것: 객체를 불러다가 메소드를 호출시켜줌

AOP란?

어떠한 메소드 코드를 실행시키전/후의 시점에서 다양한 로직들을 횡단적(세로 관점)으로 보았을 때 반복적인 로직 로직을 하나의 모듈로써 통합하여 짜는 프로그래밍

객체지향과 관점지향의 차이

• 객체 지향 프로그래밍: 잘 분리가 되어있고, 모듈화가 잘 되어있다는 뜻 필요한 시점에 객체.메소드를 호출 가능

• 하지만, 코드 중복이 일어날 수 밖에 없고, aop(관점 지향)을 적용하기 좋은 바탕이라고 생각
• 객체지향 프로그래밍은 응집도가 높고, 의존성이 낮고, 결합도가 낮고, 모듈화가 잘 되어있기 때문!

JPA(PI)<복습>

• JPA의 일꾼: EntityManager

• @Entity (cf. @Component -> ApplicationContext)

• persist(): entityContext에 추가, DB에 저장까지 해줘! = 영속화한다 entityContext: 영속화된 객체가 모여있는 공간

• @Transactional

• @Id: entityContext안에 너같은 애가 여러개 있어 식별할 수 있게 id를 부여하는 역할

EntityManager

• persist(객체)
• find(타입, 식별자) cf. Spring도 type으로 빈 구별했지.. 하지만 여기에서는 객체가 여러개이기 때문에 식별자도 필요 = 같은 타입의 객체가 1개 뿐(default)="싱글톤 패턴" 데이터베이스에 데이터를 저장하기 위해서 EntityContext를 무조건 들려서 옴 -> "class 타입"와 "id"가 필요하기 때문 왜 식별자까지 필요할까? 똑같은 객체가 여러개 존재하기 때문에 각 객체를 식별하기 위해 @Id을 통해 식별이 가능함!

EntityManager-2

• createQuery(쿼리): cf. JPA는 자바-디비 패러다임 일치 목적! => 자바는 자바스럽게, 디비는 디비스럽게
  • JPQL(Java Persistence Query Language) 자바스럽게 쿼리 짜면=> JPA가 알아서 SQL로 바꿔서 쓸게! (like 슈도 코드)
  • ex. SQL: SELECT *(컬럼) FROM room(테이블 명); JPQL: SELECT r.price(필드) FROM Room(클래스명) AS r(별칭)

• clear(): 영속성 컨텍스트를 클리어! 다 비워버리는 것!
• flush(): 영속성 컨텍스트 - DB 동기화
• close():영속성 컨텍스트를 영업 종료!

DTO관련 구현 질문?

• 왜쓰는가? -> 어떻게 쓰는가?
• DTO는 몇 개가 적당할까??
  • DTO 1개 vs 여러개: 2개 이상 만들기!
  • 사용자의 요청마다 다른 request->dto->response entity당 DTO 몇개씩 가지게 됨

• DTO <-> Entity 변환 어떤 계층?
  • Controller: DTO(클라이언트 필요)
  • Service: 변환하는 것도 로직이라고 생각
  • Repository: Service에서 연산 다했을 것이라고 믿고, repository에서 변환
• 변환 방법: 필드, setter < 생성자, builder
• Entity는 객체(행위)라기 보단 개체 : Data덩어리(행위x)
• Entity는 지켜줘야징

  1차 코드 작성

  RoomService

  분리가 잘 된것인가? NO 이유: 생성자 인자값이 바뀌거나 메소드명이 바뀐다면 다 같이 바꿔야함 그리고, 방을 저장하는 거지 방을 생성하는 건 아닌데 그 코드까지 있어야 하는가?에 대한 의문증,,,즉, service가 할일이 너무 많음!=>DTO로 코드 이동하자

JPA vs Spring Data JPA

• EntityManager를 누가 다루는가

  • JPA: 개발자가 직접

  • Spring Data JPA: Spring

  • 추상화(인터페이스 제공): 쉽고, 편하게 JPA 사용할 수 있음!

  • 대왕 인터페이스 "JPARepository"*

    (1) (List)CrudRepository (2) (List)PagingAndSortingRepository (3) QueryByExampleExecutor

    그럼 JPA->SpringJPA코드로 변환해보자!

• 가정: MAP->JPA->Spring Data JPA를 나중엔 쓸거야 변환을 하려고 했더니.... 개방 폐쇄 원칙을 위반!!!⛔️ -> 해결책: interface/추상클래스 🌟추상화🌟

• Repository가 바꾸어도 서비스가 바뀌지 않도록 하기 위해 ! 중간에 인터페이스를 둠 사실 자바세상에서 확장은 추상화말고는 답이 없어요,, 어렵조..? 다시다시 쉬운 예제로 한번 더 갈게용! 아니 그거 기억나시나요 폰 사람 예제요... 그게 무려 여기서 쓰일려고 미리 했던 거였던 거였던 거였다요... 대박!!!!!!!!!!!이런 큰그림을

여기서 잠깐,, 테스트 코드를 짜려고 했는데..

test코드가 aop가 있었다고..? aop가 test에 나와?!!?

예전의 기억을 살려 아래 코드에 먼저 적용해보쟈~

service변경없이 A, B모두 사용가능 (위세줄은 spring이 대신 해줌)하하 개편해! 아니 근데 안되자나왜 안넣어주냐고!!!! nullpointerException이 터져!개빡쳐! Test코드에서는 스프링이 일을 안하는 거구낭... 스프링 더 일하자,, 해결방안 : 클래스 위에 @SpringBootTest 추가하면 됨 그럼 스프링이 테스트에서도 일을하게 됩니당! 스프링 열일해!

음 이제 기동은 되는데 여전히 NullPointerException이 뜨네!??! 어떻게 해결해야 할까?!

• Message를 Publisher가 보내면 Queue에 담겨있다가 Consumer(Customer)가 받아 간다. cf. '큐잉(Queue)' 참고자료- rabbitMQ공식문서

  MSA뿐 아니라 여러 시스템의 통신 방식

  : 분리된 어플리케이션 (모듈)끼리 데이터를 주고 받는 (통신) 방식 ex. A service <-> B service

그럼 블로킹/논블로킹은 동기와 비동기와 뭐가 다른거지?

동기/비동기 + 블로킹/논블로킹 조합

먼저 동기와 비동기에 대해 알아보자!

동기적 통신방식

• 요청을 보냈을 때 응답이 올때까지 기다리는 것, 요청과 응답의 순서가 보장된다.
• 종류
  • REST API: http프로토콜 사용

비동기적 통신방식

• 요청과 응답의 sync가 맞지 않아도 되기때문에 동시에 다른 일을 가능하다.
  • 완료 여부 신경쓰지 않는 것
  • 요청/전달을 보낸 후, 응답과 관계없이 다음 동작 실행 = 작업이 병렬로 배치되어 실행된다. => 나중에 시작된 작업이 먼저 끝나는 경우도 가능!

• 종류

  • 메시지 큐 (Message Queue): 메시지 큐를 통해 모듈 간 비동기 메시지를 주고 받는 방식 ex) RabbitMQ, Kafka, ActiveMQ
  • Publish/Subscribe 모델: 한 모듈이 이벤트를 발행하고 다른 모듈이 이를 구독하여 비동기적으로 통신하는 방식 ex) Apache Kafka
  • 메시지 브로커(중개인) 방식(기술)

즉 동기와 비동기는 응답을 받을 때까지, 기다리냐 안기다리냐의 차이! => 이렇게 생각하면, 블로킹이랑 마치 비슷해보이는데 완료여부를 신경쓸지 말지의 차이이다.

이제 블로킹/논블로킹 , 동기/비동기의 조합의 차이를 그림으로 보자!

메시지 브로커?

• 메시지 브로커가 왜 생긴걸까? 또, 비동기여야만 하는 이유는?

• 양쪽 모두에게 자유를 주어 받아가고 싶을 때 받아가고 주고 싶을때 줄 수 있도록!! 주는 친구뿐 아니라, 받아가는 친구의 자유도 높여줌. *like kakaotalk * 즉, 서로의 자유도를 높여주기 위해 비동기 메시지 브로커를 사용한다!

예시) 주문 서비스

• 주문 서비스에서 메시지 브로커에게 주문 정보를 던져주고, 주문 서비스는 비동기적으로 자기 할 일 계속 함.
• 재고 서비스가 메시지 브로커에게 주문 정보를 비동기적으로 받아가서 재고 수량을 하나 뺀다.

종류

• 카프카(Kafka)
  • 데이터 취합 => 분산 "스트리밍"
  • Redis(공유 데이터베이스) ex. 메신저, 유튜브/넷플릭스
• Message Queue(RabbitMQ, ActiveMQ ...)

🧶 실습

• 실습 자료

1. "Hello World!"

   • 보내는 쪽

     package com.example.a_module;
     import com.rabbitmq.client.ConnectionFactory;
     import com.rabbitmq.client.Connection;
     import com.rabbitmq.client.Channel;
     import com.rabbitmq.client.MessageProperties;
     public class Sender {
     private final static String QUEUE_NAME = "hello";
     public static void main(String[] argv) throws Exception {
         ConnectionFactory factory = new ConnectionFactory();
         factory.setHost("localhost");
         try (Connection connection = factory.newConnection();
              Channel channel = connection.createChannel()) {
                 String message = String.join(" ", argv);
                 channel.basicPublish("", "hello", null, message.getBytes());
                 System.out.println(" [x] Sent '" + message + "'");
         }
     }
     }

   • 받는 쪽

     package com.example.b_module;
     import com.rabbitmq.client.Channel;
     import com.rabbitmq.client.Connection;
     import com.rabbitmq.client.ConnectionFactory;
     import com.rabbitmq.client.DeliverCallback;
     import java.nio.charset.StandardCharsets;
     public class Recv {
     private final static String QUEUE_NAME = "hello";
     public static void main(String[] argv) throws Exception {
         ConnectionFactory factory = new ConnectionFactory();
         factory.setHost("localhost");
         Connection connection = factory.newConnection();
         Channel channel = connection.createChannel();
     
         channel.queueDeclare(QUEUE_NAME, false, false, false, null);
         System.out.println(" [*] Waiting for messages. To exit press CTRL+C");
     
         DeliverCallback deliverCallback = (consumerTag, delivery) -> {
             String message = new String(delivery.getBody(), StandardCharsets.UTF_8);
             System.out.println(" [x] Received '" + message + "'");
         };
         channel.basicConsume(QUEUE_NAME, true, deliverCallback, consumerTag -> { });
     }
     }
     

2. Work Queues

• 라운드 로빈 방식으로 데이터를 받는다.

• NewTask

  //package com.example.a_module;
  import com.rabbitmq.client.ConnectionFactory;
  import com.rabbitmq.client.Connection;
  import com.rabbitmq.client.Channel;
  import com.rabbitmq.client.MessageProperties;
  public class NewTask {
    private static final String TASK_QUEUE_NAME = "task_queue";
    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");
        try (Connection connection = factory.newConnection();
             Channel channel = connection.createChannel()) {
            channel.queueDeclare(TASK_QUEUE_NAME, true, false, false, null);
  
            String message = String.join(" ", argv);
  
            channel.basicPublish("", TASK_QUEUE_NAME,
                    MessageProperties.PERSISTENT_TEXT_PLAIN,
                    message.getBytes("UTF-8"));
            System.out.println(" [x] Sent '" + message + "'");
        }
    }
  }
  

- Worker
```java
//package com.example.b_module;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.DeliverCallback;
import java.nio.charset.StandardCharsets;

public class Worker {
    private static final String TASK_QUEUE_NAME = "task_queue";

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");
        final Connection connection = factory.newConnection();
        final Channel channel = connection.createChannel();

        channel.queueDeclare(TASK_QUEUE_NAME, true, false, false, null);
        System.out.println(" [*] Waiting for messages. To exit press CTRL+C");

        channel.basicQos(1);

        DeliverCallback deliverCallback = (consumerTag, delivery) -> {
            String message = new String(delivery.getBody(), "UTF-8");

            System.out.println(" [x] Received '" + message + "'");
            try {
                doWork(message);
            } finally {
                System.out.println(" [x] Done");
                channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
            }
        };
        channel.basicConsume(TASK_QUEUE_NAME, false, deliverCallback, consumerTag -> { });
    }

    private static void doWork(String task) {
        for (char ch : task.toCharArray()) {
            if (ch == '.') {
                try {
                    Thread.sleep(10000);
                } catch (InterruptedException _ignored) {
                    Thread.currentThread().interrupt();
                }
            }
        }
    }
}

결과 화면

• 2개의 워커가 번갈아가면서 메세지를 받을 수 있다.

MSA

MSA의 장점: Scale-out

• Scale-out: 서버를 추가하여 시스템을 확장
  • 서비스가 다 나뉘어져 있기 때문에 추가 삭제 수정이 용이하기 때문(서비스가 죽지 않아야 한다!)
  • 만약, 각 서버들이 수정될 때마다 주소값을 수동으로 바꿔야 한다면?
  • Scale-out장점이 되려 단점이 되버림ㅠㅠ 관리 포인트가 늘어나기 때문!
  • 따라서, "서비스 레지스트리": 서비스 주소를 관리해주는 친구(User, Room...)
• Scalue-up: 기존 서버 사양 업그레이드

Service Registry

서비스의 위치 저장/관리 전담

• 내부 서비스 간 통신(다른 서비스 주소 필요할 때)
• 게이트웨이가 Request에 따른 서비스 주소가 필요할 때
• 사실 서비스 B, C, D가 아니라, 서비스 A 부하 분산용 인스턴스를 여러개 둘때 많이 씀 (로드밸런스도 여기서 함께 사용됨 부하를 막기 위해!)

cf. 레지스트리 윈도우 레지스트리: OS설정값, 정보를 담고 있는 저장소) => 소프트웨어들에 대한 각종 설정값, 정보를 담고있는 저장소

게이트 웨이

• 네트워크 상에서 서로 다른
  • 통신망
  • 프로토콜 끼리 통신이 가능하게 하는 컴퓨터/소프트웨어
• *"(종류가) 다른 하드웨어/소프트웨어 간 통로의 역할"**

ex) ESL, 여러개의 게이트 웨이를 통해 매장 내 가격 태그를 커버한다.

registry

1️⃣그림

2️⃣그림 1️⃣과2️⃣의 그림과 다른 점은 서비스가 직접 regitry에 주소를 저장하고, 레지스터를 참고하는 것은 api gateway단에서 진행되며 api gateway에서 뿌려준다는 것

고민한 점

로드 밸런스를 여러 개 두면, 룸과 유저에서 소통할때 부하가 너무 심해지지않을까?

• 주문 내역을 가져오기 위해 회원 ID가 필요한 경우
• 미리 인증 인가를 판단하고 들어오도록 해서 부하를 줄이자!

DB를 다 따로 사용하면, DB를 동기화하는데 어렵지 않을까?

• RDS를 사용하자!! DB서버 따로, 웹서버 따로 사용해서 하나의 DB만 사용할 수 있도록
• 그럼 위 그림에서는 RDS를 4개 사용하게 되는 거겠쪼?!

정리 MSA는 연관관계를 다 끊는 것! : user에게 요청을 하면 안된다. order객체 안에 파라미터 안에 직접 유저 아이디를 집어 넣어야하고, 객체간의 연관관계를 끊어야 하기 때문

그럼 어떻게 연관관계를 끊어야 할까?

• foriegn key를 사용하지 않고 순수한 컬럼을 사용하고,
• 메시지 큐를 사용해서 탈퇴했다는 이벤트가 발생하면 각각의 테이블을 업데이트 하는 방법

Client Side Discovery

• 서비스 레지스트리(구현체)를 직접 사용

• 대표적인 라이브러리: Spring Cloud Netflix Eureka 서비스 A와 서비스 B가 소통하고 싶을때 서비스 A는 주소를 registy에 등록하고, 서비스 B가 A의 주소를 받아와 소통함

• 장점: 구현 간단, 레퍼런스가 많음

• 단점: 각 서비스임에도 불구하고, 서비스 레지스트리에 모두 완전 의존 => 폴리그랏의 경우, 환경에 따라 여러번 구현해야 한다! cf. 폴리그랏(polyglot) 각 서비스가 다른 언어/프레임워크 환경

  Server Side Discovery

  로드 밸런스가 있는 것: 인스턴스가 여러개 4번까지 로드밸런스가 해줌 <그림에는 없지만, A외에도 B, C서비스가 존재한다> 서비스가 registy에 주소를 등록하고, 서비스 A가 직접 동사무소에 가지않고, 로드밸런스에게 대신 물어보고, B가 하려는 일도 대신 해줌 질의(주소 알아와주고) + 통신(다른 서비스와 통신)

• 장점: 로드밸런스(추상화)-서비스레지스트리(구현체)

• 단점: 네트워크 hop이 증가 = '상대적' 속도 지연

• 검증(증명) vs 검사/검정(확인)
• 백엔드 세상의 조건에 부합하는지 확인 ex. 비밀번호 규칙

추가 질문

• (1) 이미 가입된 id(중복 검사) 확인은 유효성 검사일까?

  • 맞다: 잘못된 값이라면 비지니스 로직을 돌리는데 의미가 없다. 앞단에서 유효성검사로 걸러줘야 한다.
  • 아니다: 올바른 값인 것은 맞지만 조건에 맞지 않은 것 뿐, 이를 처리하는 것은 또 다른 하나의 로직이라고 생각한다.

• (2) 검사는 어디서? 처리는 어디서?

  • 백엔드 세상 조건에 부합하는지 확인해야하기 때문에
  • 컨트롤러에서 검사를 해서 들여보낸다 백엔드 들어가기 직전에!
  • 검사에서 걸렸어 처리좀 해줘!: 처리는 서비스에서 시킴
  • 서비스가 어떤 에러에 걸렸는지 알려줌
  • 컨트롤러가 받아서 클라이언트에게 알려줌
  • 유효성 검사를 예외처리로 풀어내는 것: 어떤 필드가 문제인지 예외처리로 필터링하는 것 (예외 처리를 일종)
  • 즉, controller가 exception을 던지고, service가 받아서 처리한다. (정답은 아니고 보통 처리하는 방법)

@Valid( vs @Validated)

1) 어느 dependency 소속일까?: spring boot starter validation 2) 어떤 어노테이션과 같이 쓸까?

• @Email : 이메일 형식 검사
• @Size: 값이 min과 max사이에 속해야함 @Size(max = 10, min = 1)
• @NotBlank: 값이 비어있으면 X
• @NotNull: Null값이 아니어야 한다.
• @PositiveOrZero : 0이거나 양수인 값이다.
• @Future: 날짜 필드가 미래여야 함을 지정
• @FutureOrPresent: Now 거나 미래의 날짜, 시간이어야 한다.
• @Max(9999) Min : 최대 9999까지 허용 (최소도 마찬가지)
• @Pattern: 비밀번호 유효성 검사에 주로 사용

3) 어노테이션들은 어디에다 붙여야 할까?

• @Valid: Controller/@RequestBody @Valid DTO
• @NotNull, @Pattern...: DTO field 위

@Validation

• @Valid는 자바 표준 스펙이고 @Validated는 스프링에서 제공하는 어노테이션
• @Validated를 통해 그룹 유효성 검사나 Controller가 아닌 다른 계층에서 유효성 검증 가능
• @Valid는 MethodArgumentNotValidException 예외를, @Validated는 ConstraintViolationException 예외를 발생시킨다. AOP 기반으로 메소드 요청을 인터셉터하여 처리된다.

Validator: 유틸성 클래스

• isNumber
• isAlpha

SME 라이브러리

• 자바 표준 라이브러리(ex 컬렉션)를 확장하여 좀 더 편리한 기능을 제공하는 라이브러리
• 대표적인 예시: Apache commons, Google guava
• implemenation 'com.google.guava:guava' ex. Range.closed(1,10), Strings.inNullOrEmpty(문자열) Strings.commonPrefix()/Suffix() <-> padStart()/End(); joiner.on(문장부호).join(배열) 🌟ex) Splitter.on("&").trimResults().withKeyValueSeparator("=").split("name=gari&age=20") => {name=gari, age=20}

User + Validation

• 1단계. 회원가입할 때 조건!

  • 이름이 NotBlank

  • 비밀번호 최소 8자리 이상

  • 이메일 주소 이메일 형식에 맞게

    만약 위 조건에 부합하지 않은 값을 입력한다면?

    조건에 만족하지 않는 필드를 모두 보여준다. 그럼 위 내용들을 에러처리하고 싶은 데 어떻게 해야할까?

    방법1: Errors 파라미터에 추가

    @PostMapping("/join")
    public void join(@RequestBody @Valid UserJoinReq userJoinReq, Errors errors){
       //userService.join(userJoinReq);
       for (FieldError fieldError: errors.getFieldErrors()){
           System.out.println("Error field : "+fieldError.getField());
       }
       System.out.println("회원가입 완료");
    }

    결과화면

    방법1-1: BindingResult

  • Spring validator가 검증/검사 하다가 오류가 발생하면, 오류가 난 특정 필드 or 객체를 Errors(BindingResult)에 담음!

  • BindingResult와 Errors중 어느것이 더 구체적일까? BindingResult extends Errors : Errors를 상속하는 BindingResult가 더 구체적이다. => Errors를 상속받았기 때문에 Errors 인터페이스를 통해서 BindingResult의 유효성 검증 에러 관련 멤버에 접근 가능! cf. BindingResult는 "데이터 바인딩 에러" + "유효성 검증 에러" ex. @ModelAttribute Model model

• 그래서 유효성 검사 중 에러가 나면 어디에 담기는걸까? ** AbstractBindingResult의 필드에 addError메소드를 통해 저장함**

  방법2: 컨트롤러에서 서비스로 에러를 전달해서 처리해보자!

  @PostMapping("/join")
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public Map<String, String> join(@RequestBody @Valid UserJoinReq userJoinReq, Errors errors){
        //userService.join(userJoinReq);
        Map<String, String> errormessages=userService.handleErrors(errors);
        //Map => new ApiError(errorMessages);
        return errormessages;
    }

   @Component
  public class UserService {
    public Map<String, String > handleErrors(Errors errors){
        Map<String, String> errorMessages=new HashMap<>();
        for (FieldError fieldError: errors.getFieldErrors()){
            String errorField=fieldError.getField();
            String errorMessage=fieldError.getDefaultMessage();
            errorMessages.put(errorField, errorMessage);
        }
        return errorMessages;
    }
   }

  결과화면

  

  방법3: 에러를 global하게 처리하자

  Controller

   @PostMapping("/signup")
    public ResponseEntity<String> signup(@RequestBody @Valid UserJoinReq userJoinReq) {
        userService.join(userJoinReq); // 유효성 검사를 통과한 경우 처리 로직 호출
        return ResponseEntity.status(HttpStatus.CREATED).body("success"); // 성공 응답 반환
    }

  Global Exception

   @ExceptionHandler
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public Map<String, String > handleValidationExceptions(MethodArgumentNotValidException errors) {
        Map<String, String> errorMessages=new HashMap<>();
        for (FieldError fieldError: errors.getFieldErrors()){
            String errorField=fieldError.getField();
            String errorMessage=fieldError.getDefaultMessage();
            errorMessages.put(errorField, errorMessage);
        }
        return errorMessages;
    }

public static class ApiResult<T> {
    private private boolean success;
    private private T response;
    private private Throwable error;

    public ApiResult(boolean success, T response, Throwable error) {
        this.success = success;
        this.response = response;
        this.error = error;
    }
}

보완하고 싶은 점

• ApiUtils 굳이 없어도 될듯! 리턴을 하는 역할 밖에 안하기 때문
• null을 굳이 생성자에 들어가야 할까?
  • private fianl로 선언해서 수정이 불가능하도록 하고,
  • constructor에서 초기화하는 것 외에는 불가 constructor로 무조건 주입해야해 발생한 상황
• 차라리 성공/실패 객체를 따로 만드는게 좋을 듯

왜 이렇게 설계했을까?

• 성공이든 실패이든 같은 필드로 보고 싶어서
• 프론트 입장에서 쉽게 꺼내서 확인하고 처리할 수 있도록 하기 위해
• 프론트엔드와 협의해야할 부분일듯

참고 깃 허브 주소 코드 내 static: 객체 생성없이 사용 가능하도록 함.-> 단일책임원칙을 어기진 않음

• 클래스 내부에서 사용할 객체를 외부에서 사용자 정의해서 쓸 수 있는 기술

왜 제네릭을 쓸까? [제네릭의 장점]

1. 다운캐스팅을 안해줘도 됨=바로 꺼내쓰기 가능
2. 컴파일 시점에서 캐스팅 가능 여부 알려줌

   package com.example.summer.generic;
   

public class GenericClassDemo { private static Component t; private static Component component;

public static void main(String[] args) {
    BoxObject boxObject=new BoxObject();
    boxObject.o=new Object();
    System.out.println(boxObject.o.toString());


    BoxGeneric<Object> boxGeneric=new BoxGeneric<>();
    boxGeneric.t=new Object();
    System.out.println(boxGeneric.t.toString());

    BoxObject boxComponent=new BoxObject();
    boxComponent.o=new Component();
    Component component =(Component) boxComponent.o; //down grading을 해야하고
    System.out.println(component.field);


    BoxGeneric<Component> boxGenericComponent=new BoxGeneric<>();
    boxGenericComponent.t=new Component();
    System.out.println(boxGenericComponent.t.field);//그냥 꺼내써도 됨

    String str1=(String) boxObject.o;
    String str2=(String) boxGeneric.t;
    //String str3=(String) boxGenericComponent.t;

}

}

class BoxGeneric{ T t; } class BoxObject{ Object o; } class Component{

String field;

}

### 그렇다면 아래 코드가 가능할까?
1) String str1=(String) boxObject.o; : **NO!**
2) String str2=(String) boxGeneric.t; : **NO!**

-->String 타입으로 안전하게 사용하려면 타입 확인 및 적절한 캐스팅이 필요함!
## 제네릭 메소드
클래스와 독립적으로 제네릭을 운용(사용)할 수 있는 메소드
```java
class GenericClass<C>{
    C c;
    //제네릭 클래스
    public C methodC(C c){ //외부에서 정해준 객체 C 다 같은 것
        return c;
    }
    //제네릭 메소드
    public <M> M methodM(M m){ //<M>: 나 제네릭 메소드라고 선언하는 것
        return m;

    }
    public <G> C multiMethod(G g, C c){ //제네릭메소드꺼+ 클래스꺼 반환타입은 클래스꺼(멀티 가능)
        return c;
    }


}

예시) 아래 T들에 대해 구별해보자

class ClassWithGenericMethod<T> {
    // 클래스명 옆의 T와 같은 타입.
    // 객체 생성 시점에 정해진 타입으로 결정, 타입을 바꾸고 싶으면 해당 타입의 객체를 새로 만들어야 함.
     T t;

     // 필드의 T과 다른 독립적인 타입, 객체 생성 때와 다른 타입 가능.(덮어쓰기 가능)
     // 이때 메소드의 T는 동적 타입으로 메소드를 호출할 때마다 모든 타입 가능!
     public <T> T genericMethod(T t1, T t2) {
         return t1;
     }
}

class BoxGeneric2<T> {
    // 클래스명 옆의 T와 같은 타입으로만 가능하다.<T> 선언X
    public void test(T t1) {
    }
}

• 제네릭 메소드는 클래스 레벨의 타입과 독립적으로 메소드 레벨의 타입으로 덮어쓰기가 가능하다!

< T > 타입 파라미터

• < T >
• < S >
• < U >
• 아무의미 없음, 암묵적인 약속일뿐

• 종목들: Sports class 상속 종목 "클래스"

• 참여 국가들: Nation class 상속 국가 "클래스"

• Add종목(종목): 종목들에 종목 추가

• Add국가(국가): 국가들에 국가 추가

• print종목들(): 종목 전체 출력

• print참여국가들(): 국가 전체 출력

• GenericDemo class: psvm

쿠키가 왜 필요할까?

• 웹은 stateless이기 때문에 서로 상태를 기억하지 못한다는 것이 문제
• 포춘 쿠키 : 나의 정보를 담고 있음
• 서버가 쿠키를 구워서 클라이언트에게 주고, 들고 다녀야 서버가 확인 가능함-> 로그인 유지
• 보안이 좋지 않음: 다른 사람이 포춘 쿠키를 먹을 수 있음

그래서 나온것이 세션!

• 로그인 세션이 만료되었습니다.
• 보안이 안좋기 때문에
• 중요한 정보는 돌 밑에다 숨겨놓고 어디에 숨겨놓았는지에 대한 돌번호 정보는 쿠키에 저장해서 전달
• 세션 아이디? 돌 번호

그렇다면 JWT는?

• jwt 문서
• 정보를 암호화해서 만든 토큰
• 헤더/내용/서명
• 서버에서 생성된 토큰을 클라이언트에게 전달
• 클라이언트는 이 토큰을 저장하고, 요청 시마다 서버에 전달
• 서버는 토큰을 검증하여 요청을 처리

쿠키 vs 세션 vs JWT

쿠키

• 클라이언트 측에 저장됨
• 보안에 취약할 수 있음
• 간단한 데이터 저장에 유용

세션

• 서버 측에 저장됨
• 더 높은 보안 수준
• 서버 리소스를 사용함

JWT

• 클라이언트 측에 저장됨
• 정보가 암호화되어 있음
• 서버 확장성에 유리

• 위 그림에서 아쉬운점 AOP의 위치 : AOP는 어디서든 쓸 수 인터셉터와 컨트롤러 사이뿐만아니라!

  

  • DispatcherServlet: 순서를 결정해서 그에 맞게 불러주는 친구, 스케쥴링, http 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 알맞은 컨트롤러에 위임해주는 프론트 컨트롤러

• HandlerInterceptor: 핸들러로 가는애를 인터셉트 낚아채서 값을 체크, 검사하는 용도로만 사용함, 데이터를 건들지 않음 로그인 체크,
  • 인터셉터: 요청에 대한 작업 전(후) 가로채어 공통 작업 수행
  • res/req 낚아채서 (데이터 접근 가능 but,) 직접 다루는 일은 없어야 함!데이터를 바꾸면 안된다!
    • 사용예시 : 로그인 여부 체크, 검사

      @Configuration //스프링아 나 이 파일 설정파일로 쓸거야
      public class CustomWebMvcConfigurer extends WebMvcConfigurationSupport {
      @Override
      protected void addInterceptors(InterceptorRegistry registry) {
      registry.addInterceptor(new MyInterceptor())
       .addPathPatterns("/**");
      }
      }

    • registry(feat.MSA) 모듈 간 소통 어떻게? 서로의 주소를 알아야하잖아?!
    • 아이디어1*💡 : 대신 전달하는 전달자 역할을 하는 친구를 하나 두자! 그런데! 대신 전달자 역할 친구: 야 나 전달만 하고 싶어 주소록 관리까지 하는게 너무 힘들어! 전달하는 친구의 부하를 너무 크다ㅠ^ㅠ 부하를 줄일 방법은?

아이디어2💡 : 주소를 관리하는 친구를 따로 두자! 위 그림과 같이 주소를 관리하는 친구를 따로 두고 요청이 들어오면 주소록 친구에게 주소를 받아서 소통하는 방식을 채택함.

• 여기서 주소록 역할을 하는 친구가 registry
• 대신 전달해주는 친구가 load balancer

필터 ~ 인터셉터

✔️ 필터~인터셉터 어떻게 구동될까?🧐

• 성공적으로 Res 날아올때
• 404처럼 처리할 수 없는 요청이 날아올 때
• 아예 예외가 터져버렸을 때(/error)

🌟WebMvcConfigurationSuppor

• 잘못된 요청을 보냈을 때! 디스패처 서블릿이 일 시킬 게 없음 즉, 요청을 받는 컨트롤러가 없음 : 요청이 틀리면 전달해줄값이 없으면 받아줄 컨트롤러가 없으면 filter로 돌아가게 됨. 그럼 왜 로그가 두 번 찍히는 걸까? 요청이 받아주지 않으면 왜 response안오지? 라고 생각하고, 먼저 돌아 나가고, 핸들러 인터셉터는 할 일 하고 나감! 그래서 로그가 2번 찍히는 것! 즉, exception 에러가 터지면 controller로 다시 요청이 가서, 두바퀴돌기 때문!

• 올바른 요청 보냈을 때! 디스패처 서블릿이 리퀘스트가 날라오면 일 시킬거리인 요청만 보내기 때문에 잘 나옴 나어디 줄데 있나 있으면 컨트롤러로 보냄 핸들러 인터셉터할일 하기.. vs @autoConfiguration 자동등록해드릴게 자동등록안해줄게

  🌟 WebMvcConfigurer

• 잘못된 요청

• 올바른 요청

역할

• Data Binding: 잭슨, 역직렬화/직렬화(interceptor), requestBody

• validation

• Handler exception resolver: exception이 터지면 잡아줌

• filter: log 찍기 가능, 헤더관련된 것 처리, 인코딩(헤더값에 존재) 변환 처리, XSS 방어

  • ServletRequest/ServletResponse 객체 변경 및 조작 수행 가능
  • WAS 내의 ApplicationContext에서 등록된 필터가 실행됨. ➡️ 스프링이 알아야 한다! 스프링아 이거 필터니깐 봐줘! ➡️ 에노테이션 존재 ➡️ spring context는 bean 밖에 존재하는데 어떻게 스프링이 스캔할까?➡️ @serveltComponentScan

• chain.doFilter

  @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse res = (HttpServletResponse) response;
  
        String requestURI = req.getRequestURI();
  
        System.out.println("Filter Request - " + requestURI);
        chain.doFilter(request, response); //필터가 이 사이에서 실행될 것
        System.out.println("Filter Response - " + requestURI);
    }
  

다음 필터나 마지막 필터로 넘겨주는 것 (나 방금 이 리퀘스트 지나왔거든!)
다음 리스펀스 들고 다음 리퀘스트로 넘겨주는 것

> 💡OWASP(Open web Application Security project)
⚠️ 웹이 공격을 당하는 방법
>1. SQL Injection
>2. XSS: 버튼을 누르면 숨겨진 스크립트가 날라감
>3. CSRF(Cross Site Request Forgery): 사용자인척 웹 취약점을 공격



## 시큐리티 with 필터, 인터셉터
- 필터: 시큐리티 먹일까 말까 고민! 필터 씌울까말까 체인을 걸까 말까?
- 인터셉터: 필터로 시큐리티를 먹임 로그인을 해야만 들어갈 수 있도록 하고 싶음. 필터가 걸렸으면 **인터셉터가 등장**해서 체크해 드림! 사전 권한 체크

• 회원 등급(1~5등급, 5%) 당 할인
• 5명 선착순 (10%) 할인

  비회원 서비스=> 비회원 할인

• 선착순 할인

  회원 서비스=> 회원 할인

• 등급 할인

컨트롤러, 서비스 or 추가 클래스

input: price + a / X

output: discounted price / 0,1

당근마켓 with SOLID 원칙

1. 서비스-메소드 2개 (회원/비회원)
2. 서비스 분리 or Not

   Member

• 비밀번호 저장 : 비밀번호 암호화해서 저장 > 다른 곳에 로직 빼기: 책임 분리!

• 회원정보 조회

• ...

  할인 기능 구현 어디서 할까?

  회원 서비스에서 다 구현하기에는.. 좀,,,

  할인 정책 분리 or Not

  회원 서비스에서 다 구현하기에는 회원 서비스의 역할이 너무 많다. 분리 진행-> 인터페이스로 분리할까? 추상 메소드로 분리할까? 둘의 차이점을 먼저 보자. 둘 인터페이스와 추상메소드는 객체를 만들 수 있냐없냐의 차이가 존재하고, 인터페이스는 객체를 만들지 못하고, 생성자가 없다는 특징! 이후 결정해보자~

@Primary+@Qulifier

step1. discountPolicy가 2개

스프링은 타입이 같을때에는 이름을 보고 구별해 빈에서 골라와 의존성을 주입한다. 충격적 스프링은 천재다..! 하나의 타입으로 여러개 객체가 있으면 매개변수 이름으로 구별한다는 뜻! 하지만 추천하지 않는다. <이유: 타입으로 스프링 빈 찾기에 실패하면, 매개변수명으로도 찾을 수는 있다. 하지만, 추천하지 않는다. 불명확하기 때문 >

그렇다면 이름까지 같게 만들면 스프링이 구별을 전혀 못하게찌~? 역시 에러 발생!!-> 스프링: 야 개발자야! 빈이 2개야...뭘 넣어줘야해?라는 오류⛔️

해결방안: @Primary

@Primary를 비회원에 달아줬더니

회원임에도 0이 나오네,,1이 나와야하는데ㅠㅠ😹 그럼 MemberPolicy 도대체 어떻게 써야 할까??

방법1.

방법2.@Qulifier 애노테이션 쓰기!

드디어 해결 완료 😝

위 코드를 확장하면서...

🚨문제 상황발생🚨

• 회원은 가격과, 등급을
• 비회원 가격만 받기 때문에 인터페이스를 분리하려고 했을때... discountPolicy를

1. discount(price): 비회원,
2. discount(price, level): 회원 로 구현하려고 하는데 매개변수가 다르기 때문에 하나의 인터페이스로 추상화 실패

   해결방안

• 1. 매개변수를 리스트로 받아오면, [0]: price, [1]: level
• 2. level을 매개변수로 안받고 메소드 내에서 해결하기
• 3. 인터페이스를 분리? 어떻게 ? 상위의 인터페이스를 만들어주어 연결하기!

TradeOff

• 인터페이스를 메소드를 안써도 하나로 쓴다면? 다형성이 좋을듯, 하지만 ISP포기해야한다.
• 하지만 인터페이스를 분리한다면? 다형성은 떨어지지만, ISP원칙은 지킬 수 있다

  인터페이스 분리 원칙(ISP)

  : 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙 (컨벤션: 약속)

ISP와 다형성 실습 🧶

• BluetoothAISpeaker: volumeUp, heyGoogle();

• Marshall, JBL, Britz implements BluetoothAISpeake

  • 장점) 하나의 타입으로 여러 구현체 담아 "다형성"
  • 단점) 필요없는 메소드도 구현하는 척 해야함

• Speaker/Bluetooth/AI 인터페이스로 분리

• Marshall: Speaker, Blutooth, A

• JBL: Speaker, Blutoot

• Britz: Speaker

  • 장점) 필요한 메소드만 구현
  • 단점) 하나의 타입으로 담을 수 없다. +팔다리 접고 들어가야함...하지만

진짜?!? real? 팔다리를 다시 펼순 없는거야?

아니지 아니지

해결방안

[1] 매개변수로 받아서 사용하는 메소드를 오버로딩 [2] 상위 인터페이스를 만들어서, 팔다리 접어서 들어간 구현체를 instancof + 캐스팅을 활용하여 팔다리 다시 폄

package com.example.summer.isp;

interface ABInterface {

}

interface AInterface extends ABInterface{
    void methodA();
}

interface BInterface extends ABInterface{
    void methodB();
}

class ImplA implements AInterface{

    @Override
    public void methodA() {
        System.out.println("implA");
    }
}

class ImplB implements BInterface {

    @Override
    public void methodB() {
        System.out.println("implB");
    }
}

public class IspDemo {
    public static void main(String[] args) {
        ispMethod(new ImplA());
        ispMethod(new ImplB());
    }

    public static void ispMethod(ABInterface abInterface) {
        if (abInterface instanceof AInterface)
            ((AInterface) abInterface).methodA();
        else if (abInterface instanceof BInterface)
            ((BInterface) abInterface).methodB();
    }
}

[3] 제네릭 사용

package com.example.summer.isp;

interface ABInterface {

}

interface AInterface extends ABInterface{
    void methodA();
}

interface BInterface extends ABInterface{
    void methodB();
}

class ImplA implements AInterface{

    @Override
    public void methodA() {
        System.out.println("implA");
    }
}

class ImplB implements BInterface {

    @Override
    public void methodB() {
        System.out.println("implB");
    }
}

public class IspDemo {
    public static void main(String[] args) {
        GenericIsp<AInterface> genericIspA = new GenericIsp<>();
        genericIspA.ispMethod(new ImplA());

        GenericIsp<BInterface> genericIspB = new GenericIsp<>();
        genericIspB.ispMethod(new ImplB());
    }
}

class GenericIsp<T> {
    public void ispMethod(T abInterface) {
        if (abInterface instanceof AInterface)
            ((AInterface) abInterface).methodA();
        else if (abInterface instanceof BInterface)
            ((BInterface) abInterface).methodB();
    }
}

드디어 악명 높던 JPA를 배울 시간!✨ 그 전에 !!! JPA에 정복하기 위해서는 준비를 탄탄히 하는데 중요하게쬬?!🌟 사전 지식들을 다지러 가봅시다!

validation 유효성 검사 ?

• null이냐? not null이냐?를 알아보는 것
• 유요한 데이터인지 검사하는 것
• 백엔드/프론트엔드에서 하는 유효성검사가 다를까?
• 만약 다르다면 어떤 시점으로 보는가?
• 같은 유효성검사를 해야 할 때 어디에서 할 것인가?
  • 백엔드와 프론트엔드 둘다? 두 군데에서 모두 암호화할듯!
    • 그렇다면 중복된 로직을 사용하는 건가? NO! 다른 로직을 통해 암호화
      • 프론트엔드에서 한다면? 프론트에서 암호화해서 넘겼을 때, 백은 검사안해도 될까? 암호화 안해도 될까? -> 생각해보기!
      • 백엔드에서 한다면? 서버를 따로 띄울때 프론트엔드에서 보낸 날 것의 비밀번호를 가로챌 수 있음

데이터베이스를 왜쓸까?

• 데이터가 뭔가요❓데이터베이스에 들어가야하는 데이터
• 데이터베이스 왜쓸까? 자료구조를 왜 사용하는 지에 대한 이유와 동일하게 효율적으로 데이터를 쉽고 빠르게 사용하기 위해 사용하지!

즉 데이터베이스는 검증된 데이터가 체계적으로 모여있어서 나중에 사용할 때, 효율적으로 데이터를 찾아서 쓸 수 있는 멋진 공간이다!

• DB엔진: 코어
• DBMS: DB엔진을 인터페이스로 한겹 감싸서 managment system을 사용

  정규화/반정규화

• 정규화란? 쪼개기 : 데이터베이스의 컬럼이 많을 때, 중복된 데이터가 많을 때 중복된 데이터를 많이 사용하면 메모리 사용량이 크고, 불필요한 비용이 듦

• 유지보수에 좋음

• 반정규화란? 합치기 : join을 많이 해야할 때, 데이터를 조회할 때 많은 시간이 걸릴 때

  최대 제 3정규화까지 사용!

  • 🌟 sub query
  • 🌟 select join
  • 🌟 union

EOF exception은 언제 발생?

• connection이 끊겼을 때
• 권한이 없을 때
• 도커에서 포트 넘버가 다를때 3307:3306 외부에서 도커 들어울때, 안쪽에서 처리할때 각각 포트 넘버

  이제 본격적으로 JPA(+jdbc)에 대해 배워봅시당~!☛ 다음 블로그

패러다임이란?

한 시대의 사람들의 견해나 사고를 근본적으로 규정하고 있는 인식의 체계. 또는, 사물에 대한 이론적인 틀이나 체계.

흠... 쉽지 않은데.. 자바세상과 DB세상에서 데이터를 다루는 룰? 이라고 해석해보자!

✅ 그럼 자바세상과 DB세상의 룰 차이는 뭘까?

먼저 자바세상의 규칙을 보자! ✔️자바는 데이터를 "객체"로 다룬다. (객체 지향적) ✔️DB에서는 "데이터" 간의 "관계"를 표현한다.(데이터 지향적, sql지향적)

🌟 예시: 호텔과 룸

✔️fact: 호텔은 여러개의 방을 가지고 있다 -> 1 : N 관계

Q. 그럼 자바 세상에서는 어떻게 호텔과 방의 데이터들을 표현할까? 호텔 클래스에 방 객체를 리스트 형태로 포함하고 있다!

Q. 그렇다면 DB 세상에서는 호텔과 방의 관계를 어떻게 표현할까?

위 erd설계와 같이 일대다 관계로 호텔과 방을 연결하였다!

정리

자바세상과 DB세상에서는 1:N 관계를 나타내는 방식이 다르다. : 일대일/일대다 관계에서 id로 연결하느냐/객체로 연결하느냐의 차이가 존재 -> 객체 사이의 연관이 있을 때 문제가 생김 자바: 상속, 계층 관계 "객체 세상" DB: 매핑, 동등 관계 "데이터 세상"

✨그렇다면 자바와 DB의 데이터를 다루는 데이터의 기본 단위(자바: 객체, DB: 데이터)가 다른데 어떻게 자바에서 데이터를 저장해야 할까??

둘 중에 하나가 양보해서 한쪽의 방식에 맞춰준다면 가능하겠지만, 서로가 양보할 수는 없어❌ 양보하는 순간 자바와 DB의 가장 중요한 특성을 잃어버리기 때문이지ㅠㅠ 🤔: 그럼..방법이 모야?! 자바에서는 데이터를 저장할 수 없는거야?!!!

😀: 하나의 방법이 있긴해.. 자바와 DB 사이 에서 중개자 역할을 해주는 어떤 것이 존재하면 되잖아!

두둥!! 이런 니즈로 인해 ⚡️ JPA(JAVA Persistant Api)⚡️ 등장한 것이야

JAVA에게 꼭 필요한 JPA는 서로의 특성을 유지해 자바는 객체 지향 설계를, DB에서는 관계 지향 설계를 할 수 있도록하는 역할을 하지

그럼 다음 블로그에서는 JPA를 본격적으로 들어가기 앞서 지식을 정리해보자!

들어가기 앞서....

음...제가 한번 JPA 경험을 해봤는데요.. 정말 매콤하더라구요 😂 단단히 마음의 준비 하시구요! 천천히 JPA에 스며들어봅시당..!

먼저 JDBC부터!

✔️ JDBC의 특징

• JDBC는 사실 api!
• JDBC를 한겹 더 싸는 것이 myBatis이고,
• default: 하이버 네이트 사용
• sql을 통해서 직접 객체를 mapping하는 역할

JPA는 해결사!✨

앞 포스팅에서 JPA가 필요한 이유는 말씀드렸쬬?! 그럼 JPA가 얼마나 중요한지 체감하신걸로 알고! 넘어가겠습니당 먼저 maven repository에 들어가서 jpa을 검색해볼까요~? maven repository에서 찾은 JPA repository에 jdbc가 포함되어 있는거 보이시나용?! JPA는 사실 JDBC를 포함하고 있는데요 JDBC만으로 sql를 통해서 직접 객체를 mapping하는 것도 쉽지 않았다고 합니다... 그래서 JDBC를 포함하고 있는 JPA가 이 중대한 문제의 해결사‼️라는 말이죠.

(cf. ORM: 객체와 관계를 mapping하는 것) 위 그림과 같이 JPA(+JDBC)가 자바와 mysql사이에서 데이터를 요청하고, 제공하며 mapping시켜주고 있네요.

코드 적용1

이론으로 배웠으니 이제 코드에 적용해봅시당

Q. MySQL과 JPA를 깔고 싶은데 어떻게 해야할까요? ▶︎ 간단합니당 인텔리제이의 build.gradle파일에 DB설치 명령하면 되게쬬?! 코드

implementation 'mysql:mysql-connector-java:8.0.31' //mysql을 사용할거야!
implementation 'org.springframework.boot:spring-boot-starter-data-jpa:3.3.2' //jpa를 사용할거야!

위에서 언급했다시피 jpa안에 jdbc가 포함되어 있기 때문에 jdbc코드는 추가하지 않아도 됩니다. 또 버전을 추가로 적지않아도, 안정화된 최신 버전을 자동으로 다운해줍니다!

Spring Data JPA는 또 뭐야?

• JPA와 Spring Data JPA와 같을까 다를까용?
• JPA와 같기도 하고 다르기도하다...! 스프링이 기존 JPA+스프링 추가 기능을 덧댄 것이 Spring Data JPA이기 때문이죠!

즉 , spring이 우리가 JPA를 더 편하게 쓸 수 있게 도와주는 것! "Spring Data JPA"는 더욱 추상화한 인터페이스이다! 로 정리할 수 있겠네용

JDBC에서 일하는 친구

• DataSource: "JDBC주요 일꾼"으로 무슨역할을 할까?

  • DB와 소통 역할
  • 데이터를 주고받을 터널을 뚫을 주는 객체

• jdbc 구현체: Hikari

코드 적용2 - 데이터 소스

application.propertiesn <프로젝트 속성> 코드 추가

1) DB 연결(JDBC를 사용하려면, 'DabaSource 객체'속성)

    spring.datasource.driver-class-name=마리아db
    spring.datasource.url=내 컴퓨터에 있는 디비
    spring.datasource.username=dbwjspdla
    spring.datasource.password=비밀번호

spring datasource 공식문서

2) 포트 넘버 바꾸기 3) 프로젝트 이름 바꾸기 4) 로그 파일 경로

주의할 점 + 막간지식

• yml: 코드의 중복을 해결하는 파일형식 (트리구조)
• xml: <> 파일 형식
• 데이터베이스도 일종의 웹서버처럼 데이터 베이스 서버역할을 하기 때문에 port번호가 필요한 것
• jpa는 기본 속성이 없어서 필요한 것만 추가해야 함

DB API들의 구현체 내 주요 객체

• JDBC <복습>
  • 구현체: Hikari(패키지)
  • 주요 객체: DataSource
• JPA
  • 구현체: hibernate(패키지)
  • 주요 객체: EntityManager: persistant 운동장에서 열심히 일하는 일꾼
  • EntityManager는 어디에 구현되어있을까? 직접 찾아봅시다!! ⬇️
    • Spring Data JPA
    • 구현체:
  • 주요 객체:

    여기서 생긴 궁금증❓

    dataSource와 EntityManager를 우리는 등록한적이 없는데 어떻게 등록되어있는 걸까yo?!?! @AutoConfiguration애노테이션을 통해 스프링이 자동으로 미리 등록해준다고 합니다!! 스프링 짱!🫡

Entity method

참고 자료

• persist(Object entity): 새로운 엔티티를 영속성 컨텍스트에 추가+저장
• merge(T entity): 분리된 엔티티의 상태를 현재 영속성 컨텍스트와 병합
• remove(Object entity): 영속성 컨텍스트에서 엔티티를 제거
• flush(): 영속성 컨텍스트의 변경 사항을 데이터베이스에 즉시 반영
• clear(): 영속성 컨텍스트를 비운다.
• close(): EntityManager를 닫는다.

JPA가 어떻게 영속화를 해줄까?

• Entity: 나 영속화되고 싶은 객체/영속화가 된 객체

  • @Entity 어노테이션을 클래스 위에 달아두면,
  • EntityContext(영속화가 될/된 객체 공간)에 들어가고 싶어!라는 말!

• EntityManager:

  • persist(): EntityContext에 Entity를 모아둠 + 테이블에 저장 그렇다면... Entitycontext에 없는 객체를 테이블에 저장할 수 있을까❓NO! EntityContext에 추가되어야 테이블에 저장됨!!!

• EntityContext:

• ORM JPA의 최고 일꾼 EntityManager가 ORM을 해줌 어떻게? 영속성을 지키고자 하는 객체를 entityContext에 넣어놓고, entityManager가 entityContext를 보고 오? 너 영속화 되길 원하는 구나 ! 내가 해줄게 해서 ORM을 실시!

  🔮정리

  자바와 DB사이(정확히는 자바 끄트머리)에 엔터티 컨텍스트가 있고, 둘 사이를 데이터가 왔다 갔다하려면, 엔터티 컨텍스트에 꼭 들렸다 와야한다. 이를 담당하는 것이 EntityManager!

코드에 적용을 해봅시다!

@Component
public class RoomRepository {
    EntityManager entityManager;
    public RoomRepository(EntityManager entityManager) {
        this.entityManager = entityManager;
    }
    Map<Integer, Room> roomTable=new HashMap<>();
    int idx=0;
    public void saveRoom(Room room) {
        entityManager.persist(room);
    }
}

@Entity
public class Room {
    int id;
    private String type;
    int price;

    public String getType(){
        return type;
    }
}

⛔️ 오류가 발생함.. 무슨 오류일까?

위 사진을 보니.. @Id가 필요하다구 왜..?!?!

이유: DB에 들어가면 id가 생기겠지만, EntityContext내에서는 id가 없음-> @id: 룸들을 식별하기 위한 식별자 EntityManager가 EntityContext안을 보는데 똑같은 애들room들을 식별하기 위해 붙여주는 것 Id를 만들어서 식별해줘야겠다!

해결: @Id를 통해 식별자로 쓰면 돼!

다시 코드 적용

@Entity
public class Room {
    @Id //추가
    int id;
    private String type;
    int price;

    public String getType(){
        return type;
    }
}

⛔️ 다시 실행했더니 아래와 같이 transaction 오류가 뜨네

또 뭐가 문제야!!

• transaction: 로직 단위 여러개-> service에서 처리

  해결: @Transactional로 처리

  코드에 다시 또 적용해보자!

  RoomService
  @Transactional
    public void saveRoom(Room room) {
        roomRepository.saveRoom(room);
    }

  오 드디어 !!200 Ok가 떴지만, id가 자동으로 만들어지네 나는 id를 따로 생성한적이 없는데 어떻게 자동으로 만들어지는 걸까?!?🤔

• entitymanager가 식별할 수 없어서, entity context에 들어와야 저장 가능한데 id가 없음 그럼 아이디가 어떻게 만들지? db한테 가서 아직 저장하지 말고 잠깐만 해봐봐 id만들어볼게 rollback도 가능해! id 만들었어 1가지고 와서 entity로 만드는 것 transaction을 왜 만들까? 잘못하면 db에서 만든 id를 rollback해야할 수 있음 db야 내가 관리하기 전이긴 한데 너가 id좀 만들어줬으면 좋겠어 저장은 하지말고 저장해보더니 1이던데? 이제 entity식별 가능하네 다시 db에 저장완료!

post=> getter가 있어야 함 나머지 =>setter가 있어야함?

드디어 끝! 😝

예외처리 끝장내자!

📖 복습

• Unchecked: Runtime(Call stack) 구동

  • 링킹 흐름/호출 스택 안에서 어디에서든 처리를 하면 된다!

• Checked: Compile시 구동

  • 예외 처리를 하지 않으면 컴파일 오류 발생 해결 방안 1) 예외터진 곳에서 직접 try catch로 처리 2) throws를 사용해서 책임 전가 처리
  • 예외를 전달받은 곳에서 예외 처리를 해야만 함!

• Handler: 자동으로 호출되는 메소드

  그런데.. unchecked exception은 진짜 어디에서든 처리하면돼..? 진짜로?

  아닛 정신차려! 우리에겐 세가지 선택지가 있어!

1. 앞서 실습한 에러 터진 곳에서 바로 처리-> 이건 checked exception에서는 필수로 해야해!바로 처리안하면 컴파일 에러 생기거등!!
2. controller에서 처리
3. global하게 처리

1번은 앞선 포스트에서 실습했으니깐 2번부터 배워보자!!

• @ExceptionHandler

  : 예외가 터지면 자동으로 호출되는 메소드 at Controller(무조건 컨트롤러에서만 실행됨)
• 예시

   @ExceptionHandler(value = RoomNotFoundException.class) //이 예외 발생하면 아래 메소드 실행할거야!
    public String catchRoomNotFoundException(RoomNotFoundException e){
        return e.getMessage();
    }

  
  • value가 없어도 실행가능: 인자 예외 클래스를 통해 스프링이 추측 가능하기 때문!

• 궁금증1❓RoomController의 Request를 처리하다가 발생한 예외를 AccommodationController에서 @ExceptionHandler로 처리가능할까? 직접 한번 해보자 ! Room controller코드를 Hotel controller코드로 이동만하고 실행했더니... 오류발생.. 그렇다면 답은 ❌NO❌

• 궁금증2❓RoomController랑 AccommodationController가 같은 예외를 같은 방법으로 처리한다면? Ex. NullPointerException -> "없음!" => 다른 Controller끼리는 @ExceptionHandler 공유 ❌

두 군데에서 같은 로직을 중복되게 짜야한다는 말이야...? 너무 비효율적인데, 개발자가 이걸 두고만 봤을리가 없징,,ㅎ

=> 아이디어: totalController를 만들어서 그 안에 넣자! 그렇다면 totalController역할을 하는건,,?

• 바로 @ControllerAdvice

  : AOP가 없으면 일어날 수 없는 어노테이션 : 모든 controller들의 공통 Exception 처리 클래스 생성 가능!! : 모든 컨트롤러에 예외가 발생하면 낚아챌거야!!라는 의미 가진 어노테이션 이거면 다양한 컨트롤러에서 발생하는 중복된 에러를 처리할 수 있겠당! 실행했더니 400번 오류가 뜨네 😭 뭐가 문제일까?

• 해결: @RestControllerAdvice을 사용 @RestControllerAdvice=@ControllerAdvice+@ResponseBody (ResponseBody에노테이션은 반환을 뷰로 하지 않고, 데이터로 넘겨줄거야! 라는 의미)

그런데 왜 아직도 200번 OK로 오는거지..?! 거슬린다💥 200번이 아니라 오류니깐 400이나 404 응답 코드를 보내줬으면 좋겠엉! 이때 사용하는 어노테이션이 @ResponseStatus!

@RestControllerAdvice
public class GlobalExceptionHandler { //모든 컨트롤러에 예외가 발생하면 낚아챌거야!!
    @ExceptionHandler(value = RoomNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public String catchRoomNotFoundException(RoomNotFoundException e){
        System.out.println(e.getClass());
        return "No Room!!!";
    }
}

🎉성공!!🎉

~~### 진짜 어디에서든 처리하면 된다고..?!

controller에서 처리

응답을 보내는 곳이 controller이기 때문에 에러처리+응답코드와 함께 보내는게 좋을듯 unchecked exception은 어차피 controller에서 처리하니깐 프론트엔드에게 돌려주기전에 한방에 모아서 처리하자

예외가 터지는 곳에서 처리

우회를 시켜주자 다른 방향을 제시해주자 ~~

로그 찍기 in JAVA

slf4j 공식문서

• logger

• log level: 로그에도 단계가 있는데 warning, error, 큰 에러, 정보 제공성 로그 등 시스템마다 로그의 목적이 다른 경우가 있음 따라서 레벨에 따라서 로그를 찍어줌 그런데 레벨을 설정하면 다른 레벨이 뜨지 않음

  • Trace: 중요도가 매우 낮은 정보

  • Debug: 진행상황 체크(심각도, 중요도 낮은 정보)

  • info: 진행상황

  • warn: 잠재적으로 유해한 이벤트

  • error: 오류 이벤트(치명적인지 여부는 상관 없음)

    예시

    @RestControllerAdvice
    @Component
    public class GlobalExceptionHandler { //모든 컨트롤러에 예외가 발생하면 낚아챌거야!!
    private final org.slf4j.Logger logger=LoggerFactory.getLogger(GlobalExceptionHandler.class);
    
    @ExceptionHandler(value = RoomNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public String catchRoomNotFoundException(RoomNotFoundException e){
      logger.error("exception class: {}", e.getClass());
    //        System.out.println(e.getClass());
      return "No Room!!!";
    }
    

}

 ![](https://velog.velcdn.com/images/gari_guri/post/4afde22a-2e24-4a4d-8604-51cdf05726f4/image.png)


- 프로젝트 환경에서 로그 레벨 지정 가능
```java
resorces/application.properties
#log level setting
logging.level.root=warn (ex. 로그 레벨: warn로 지정)

• 서버 환경에서도 별도로 로그 레벨 지정 가능

  • 개발 서버: debug
  • 운영 서버: info설정 권장

• 이번에는 @slf4j인터페이스를 사용해서 로그를 찍어보자 엥 에러가 뜨네 왜 에러가 뜰까? 아하! annotatioProcessor를 추가안해줬구나! 그럼 annotationProcessor의 역할은? 컴파일시점에서 annotation을 읽어주는 역할이구나!

• 결과

예외처리를 어디서 하는게 좋을까?

나는 예외 처리를 예외가 발생한 메소드에서 바로바로 처리하는 것이 더 좋다고 생각한다. 그 이유는...

• 예외 처리를 모아서 한번에 처리하는 로직은 발생한 에러들을 계속 가지고 있어야 하기 때문에 성능 저하와 메모리 사용의 문제 발생
• 반면, 에러가 발생한 클래스에서 바로 에러 처리를 하게 된다면, 에러를 놓치지 않고 꼼꼼히 처리 가능
• 또, 코드를 읽을 때 어떻게 에러를 처리했는지 바로 파악 가능하다는 점까지! 그 외의 장점들이 있겠지만, 개발자 입장에서 에러 처리 코드를 구현할 생각을 하니깐 중복된 로직이 많을 것 같다는 단점이.....있을 것 같네용..ㅎ

그럼 위 방법 외에 어떤 방법들이 있을까?

에러처리 위치

1. 로컬 (함수 내부) 예외 처리
2. 중간 레벨 (모듈 또는 클래스 레벨) 예외 처리
3. 글로벌 (전체 애플리케이션 레벨) 예외 처리

이렇게 3가지 방법이 있고, 위에서 내가 언급한 방법은 1번에 속하는 거겠져,,?!

그럼 이 세가지 방법의 장단점에 대해 공부한 후, 나의 주장이 달라질 수도 있다는 생각이 막 드네용..!

에러처리 1번 예시

public Room getRoom(int id) {
    RoomfoundRoom=roomTable.get(1d)://0W있지모르고쓸때예외가터짐
    try{
        if(foundRoom! =null)
            return roomTable.get(id);
        else
            throw new NoSuchElementException ("No room!");
    }catch (NoSuchElementException e){
        return new Room;
    }
｝

NO room! 메시지가 출력되었다.

에러처리위치의 장단점

로컬 (함수 내부) 예외 처리

• 장점: 즉각적 처리, 세밀한 제어, 지역적 범위
• 단점: 중복 코드, 복잡성 증가

  중간 레벨 (모듈 또는 클래스 레벨) 예외 처리

• 장점: 코드 재사용성, 모듈화
• 단점: 추적 어려움, 일관성 부족

  글로벌 (전체 애플리케이션 레벨) 예외 처리

• 장점: 중앙 관리, 일관된 처리, 로깅 및 모니터링
• 단점: 지연된 대응, 상세 정보 부족, 복잡한 제어 흐름

음....각 방법마다 장단점이 너무 뚜렷해서 프바프(프로젝트 바이 프로젝트) 상바상(상황바이상황)인것 같습니당

. . . 그럼 다음 블로그에서 상황에 따라 어떻게 예외처리를 하는지 포스팅해볼게요!! 많관부😝 다음 블로그

예외란?

예상된 결과 외의 다른 결과 원하는 것이 아니거나 의도치 않은 경우

💣 예외(오류)를 경험해보자

• 위코드를 실행하면 nullpointerexception 오류가 발생한다..펑..!💣
• 오류가 발생한 이유는 뭐고, 어디서 터진걸까? id을 통해 찾은 결과가 null인데 .getName()을 적용하였기 nullpointerexception 아무것도 존재하지 않는다는 의미의 에러를 발생한다. (cf. 참조 자료형이기 때문에 null** pointer** 에러가 생김)

발생한 에러처리는 어디에서 해야할까?

첫번째 궁금증. 호출을 당한 곳에서 에러처리를 해야해? 아니지! 호출을 한 곳에서 에러처리를 해야되지!! 그게 매너아니겠어?!

먼저, if else를 걸어서 에러 처리를 해보자!

코드를 짜고보니깐 맘에 들지 않는 점ㅎ

1. 중복 코드가 너무 많으니깐 아래 코드로 일단 고치자!
2. null자체가 에러인데 이걸 반환해..? 좀 거슬리네!! 폭탄 돌리기하는 것도 아니구,, 이것도..내가 처리해야하는거 아닌가..? 그럼 null을 바로 반환하지말고 한겹 포장해서 보내자!

⚠️주의할 점 한쪽에 몰려서 에러를 처리하는 것보다 적당량을 나눠서 처리하는 것이 좋음

Optional의 등장 ‼️두둥‼️

• 장점: 언제든 npe가 터지지 않게 null을 한겹 포장해서 보내자! 받는 즉시 NPE가 터지는 걸 막을 수 있고, 받는 애는 까기 전까지는 에러가 터지지 않게 하기 위해! -> Optional class(java)

  쉽게 말하자면, Optional: 포장지같은 용도로 null인지 아닌지 확인할 수 있도록 껍데기를 싸는 것이다!

Optional 메소드

• isPresent(): 안에 값이 있나 없나?
• get(): 안에 있는 값을 꺼내는 것 => 이렇게 쓸거면,, 왜 return null 안쓰고 굳이 optional쓰지?

[안에 값이 없을 때]

• orElse(기존에 있는 객체): 안에 값이 없을때, 기존에 있던 객체를 대입

• orElseGet(새로운 객체를 생성해 달라고 요청하는 함수): 안에 값이 없을 때, 디폴트 값으로 새로운 객체를 대입(이거 가져가서 써~! )

• orElseThrow(새로운 객체를 생성해 달라고 요청하는 함수): 안에 값이 없을 때, 예외 객체로 처리해줘~

⚠️주의⚠️

• get 사용금지 return null을 하기위해 존재하긴 하지만, null을 확인하고 넘어가는게 목적이기 때문에 지양하는 메소드이다. 대신 orElse throws orElse get을 쓰자! Supplier? 예외 클래스를 받아서 처리? 함수가 반환하는 값을 쓰고 싶은데 근데 그 함수를 한번만 쓸거야, 함수로 따로 빼기에는 굳이? 매개변수로 함수가 들어가고, 함수의 반환값을 받아주는 타입이 supplier orElseGet 내가 예외 말고 객체를 만들어줘! orElseThrow 야 없다 내가 만들어둔 예외 터트려! lambda? 내가 원하는 Exception 예외 클래스를 발생시키기 위해 사용 : new 예외 클래스를 생성시키는 문법으로 lambda를 간추려서 보낸 것
• ispresent 사용금지 우리가 짤 수 있는 코드를 Optional에게 전가한 것이기 때문
• 여기서 퀴즈~! field에 Optional을 쓰지 않은 이유는?

1. 직렬화가 되지 않음-> 포장지를 어떻게 쌀거야...
2. null을 대체하는데 null이 보통 클래스에서 어디에 위치할까? 뭐할때 등장 ? 꺼낼때만 등장 null을 타입으로 써본적은 없음 return null을 대체하거나 반환타입을 대체하려고 나온 것이기 때문에 field에서 사용하는 것은 고려하지 않았기 때문에 필드에서 사용하지 않음

• map lambda string 문법을 잘 사용하지 않음 없어도 구현이 가능하기 때문! return null을 할 일이 언제일까? 없는 값 조회할때 아무것도 없네? null을 던졌다가는 객체를 줄 것이라고 생각할텐데 프로그램이 죽을텐데

  결국 Optional은 프로그램의 안정성을 위해서 사용됨 cf. 영속성: 영원히 지속하는 것 jpa는 java persistant api 자바(객체)가 영원히 지속될 수 있도록 도와주는 api로 optional이 유명해진 이유이다!

예외처리 방법

1. try catch (finally)

   try{
    // 예외 발생할 일이 없는 로직 -1
    // **예외가 발생할 수도 있는 로직**
    // 예외 발생할 일이 없는 로직 -2: 예외 터지면 실행 X finally에 넣거나 밖에 두면 됨
   }catch(예외 클래스 e객체){ //예외가 터진 로직이 발생한 예외객체를 매개변수에 넣어줌
    // 예외 처리
   }

2. throw: 개발자가 임의로 발생시키는 예외 = 자바 입장에서는 예외가 아님. Null을 보내기 좀 그러니깐, null을 받을 수 있는 room을 상속받아서 NullRoom을 return하자!

3. throws: 예외가 터졌는데 내가 터트린게 아냐! 나를 부른 상위메소드에게 예외를 던지는 것 = 예외에 대한 책임을 전가

• unchecked: 런타임 시점 ex.NoSuchElementException => 호출 흐름상 어딘가에서 catch해주면 됨!
• checked: 컴파일 시점 ex.IOException (아직 어떤 클래스끼리 호출하는지 "흐름" 모름 : A클래스와 B클래스연결(링킹)이 컴파일 이후 일어남 따라서 누가 처리를 해줄거라는 인지가 되지 않기 때문) => throws를 쓰지 않으면, 컴파일 에러!

Repository Service

try-catch안쓰고 throws쓰는 이유는 "나 에러 발생시킨다!!"를 명시적으로 보여주기 위해

예외 클래스

위 표에서 잘못된 점⛔️ 3번째줄: 자바예외 클래스에서는 roll-back을 해주지 않는다. (스프링은 가능) JAVA 세상에서는 roll-back하지 않음, roll-back 함-> roll-back을 해야 함으로 변경해야 한다.

올바른 표 ✅

사용자 예외 클래스 생성하기

• NoSuchElementException을 상속받아 사용자 예외 클래스를 생성한다.
• 위는 자식(자신의) getMessage메소드를 사용하는 코드
• 위는 부모 getMessage메소드를 사용하는 코드

마무리~ 예외 클래스를 구체화하면 좋은 이유

• 에러를 잡기가 쉬워요! = 추적하기가 쉽다.
• 어떤 에러인지 알 수 있어요! = 의미를 가지게 할 수 있어요 =>** 클래스명 구체화 가능**

• 404 (Not Found) : 클라이언트가 요청한 자원이 존재하지 않음 못찾는거야~
• 405 (Method Not Allowed): 요청이 허용되지 않은 메소드임을 의미 서버에서 해당 요청 HTTP 메소드에 대해 기능을 제한/금지함 야 하지마! 금지야!
• 501 (Notimplemented): 요청에 대해 구현되지 않아 수행하지 아니함. 다만 앞으로 영원히 기능을 지원하지 않는다는 의미보다는 추후에 기능이 개발되면 지원한다는 의미가 더 크다.

미안 내가 아직 구현 안했어... 예시) https/http로 맞추어 줘야함!

업데이트 중..

1대1

• 예시? 소개팅, 한 유저당 하나의 위시리스트, 신분증-사람, 회원-비밀번호

1대다

• 예시? 팬미팅, 지도교수님은 한 명-학생은 여러명, 사람-신용카드, 유저-리뷰 , 호텔-호텔방, 팀-학생, 하나의 가게-여러개의 리뷰

❓ fk가 있는 팀이 1? 없는 팀이 1?

** 🅰️ 없는 팀이 1** 이유는❓ 위 테이블에서 호텔은 여러개의 방을 가질 수 있으므로 호텔: 1이고, 방:N이다. 만약 호텔에 방에 대한 fk가 존재한다면 데이터가 중복되는 상황이 발생하기 때문! 방 테이블에 데이터가 추가된다면, 방 테이블의 fk에 호텔의 id가 저장됨

다대다

• 예시? 과팅, 수업-학생

다대다 테이블 예시

<과목> JAVA-홍길동, 김구리 DB-김가리 <학생> 홍길동-JAVA 김가리-DB 김구리-JAVA

초기 테이블 세팅

학생이 과목을 수강하는 거니깐 학생 테이블에 FK를 추가하자! 1️⃣테이블

오잉 ?! 그럼 같은 원리로 과목 테이블에 FK를 추가하는 것도 가능하잖아! 2️⃣테이블

그럼 두 테이블에 모두 추가하자! 3️⃣테이블

위 테이블들의 문제점은 뭘까?

• 😓 1️⃣번, 2️⃣번, 3️⃣번 테이블 만약 수강이 끝났다면,학생 테이블에서 학생을 아예 삭제할 수 없으니깐 학생/과목 테이블에서 fk를 제거해야한다. 하지만, fk를 삭제하기 위해서는 연관된 과목 테이블의 행을 삭제해야한다는 불편함이 존재한다!

• 😓 1️⃣번 테이블 특정 과목을 수강한 사람의 이름을 찾고 싶은 경우, 보통 fk를 들고가서 pk를 찾지만, 위 테이블에서는 pk를 보고 fk를 찾는 상황이 발생할 수 있다..

• 과목 테이블을 조회하고, 학생 테이블을 조회해야 하므로 불필요한 조회가 발생한다!

• 😓 2️⃣번, 3️⃣번 테이블 여러 명이 한 과목을 수강할 경우, 과목 테이블에 리스트 형태로 컬럼에 넣어야 하고, 리스트 형태를 풀어서 테이블에 저장한다면 데이터 중복이 발생한다.

다시 말해서, M:N을 쓰면 안되는 이유는?

• ⭐️ 속성의 원자성을 위배 ⭐️: 하나의 컬럼에 리스트를 넣을 수 없음 (해결: RDB, noSQL사용 cf) RDB를 왜쓰는지? 다른 테이블의 원하는 데이터를 가져올 수 있음 우리의 뇌가 관계형 데이터들을 찾을 수 있도록 설계되어 있기 때문!)
• ⭐️ 이중 조회 ⭐️: 특정 과목을 수강한 학생 조회 및 특정 학생이 듣는 과목을 조회할 때 불필요한 조회가 발생!
• ⭐️ 유지보수 및 확장성 저하 ⭐️: 데이터의 추가 및 변경이 일어날 시 데이터를 모두 수정해야 한다.
• ⭐️ 데이터 중복의 문제 ⭐️: pk의 중복이 발생하여 참조 무결성이 훼손된다.

해결책

위와 같은 문제들을 어떻게 해결하면 좋을까? 두 테이블 사이에 예약 테이블을 새로 만들자!

이상적인 테이블

✅ 수강 테이블을 따로 두어 테이블 수정 삭제, 추가 시 발생하는 문제를 해결할 수 있음

• 동사는 사용 지양 ⇒ 행동은 method로 나타낸다

• 복수, 단수 통일 ⇒ 프론트가 헷갈리니까!

• _ 사용 금지 ⇒ 대신 하이픈(-) 사용

• 소문자 사용 ⇒ 의미를 알아보기 쉽게 하기 위해

• 마지막에 슬래시를 포함하지 않는다 ⇒ 후행 슬래시는 의미가 없다

• URI 사이에 연관 관계를 있는 경우 /리소스/고유ID/관계있는리소스 순으로 작성 ex) users/profile/{userId} (X) user/{userId}/profile (O)

• 전세계적으로 "규칙" -> 무조건 지켜야한다? NO!

  ✅ DTO의 필요성을 느끼다..

  회원 API 설계

• 로그인

  • id,pw req: id/pw res: name

• 회원가입

  • id, pw, name, email, address, contack req: 필드 전부 res: id

    회원가입과 로그인에서 주고받는 정보가 다른데,,, User라는 하나의 객체만 생성하는건 비효율적이야! 그럼 객체를 여러개 만들어야 할까..? 그럼 DB도 여러개를 만들어야 하나...?!? 🤯 어떡해야하지 ->DTO가 해결: 객체를 변환(아직 코드 완성은 못함..to be continued..)

    어떻게 객체를 변환할 것인가?

• 어디서(클래스 위치)?

• 어떻게(방법)?

  • 생성자
  • 빌더의 장점=생성자의 단점: 파라미터에 뭘 넣어야 할 지 모름
  • setter
  • copy product : 생성자, builder, setter
  • map contructor

• +객체 분리 기준/각 역할

  ✅ DTO가 왜 필요할까?

  하나의 객체, 데이터가 repository까지 들어갔을 때 장점? 단점? 단점:

• 클라이언트에게 굳이 ~ 전달되지 않아도 되는 데이터 포함 ex. 시스템 활용 데이터(생성/수정 일시) -> 네트워크 비용만 올라가고, 보안 안 좋음 (hint. 극단적으로 생각해보기!)

• 클라이언트가 필요한 데이터 미포함 ex. 구현 코드 연관관계 X -> 화면에는 같이 뿌려줘야 하는 경우 ex. 생년월일->나이

1️⃣ 예시1) req->dto안에 사용하는 필드만 넣어서 통채로 반환 서비스 코드를 바꾸지 않게 전달 가능 먼저, a 객체가 그대로 db로 들어감 처음 ui/ux에 맞춰져서 설계됨. 이후, 화면 단에 하나가 더 추가되었을 경우, 입력을 받았는데 db저장 용도가 아니 연산하려는 용도일 경우 (예를 들어, mbti, 저축, 자산, 대출, 부동산와 같은 정보) 종합적으로 평가 db에 "소비성향"으로 저장해두는 경우) 즉, 당장 db에 저장할 것은 아닌데 화면 단의 내용이 바뀌는 경우

• 일단은 시스템 안쪽까지 들고오는게 문제가 됨!
• 해결: 중간에 끊으면 앞까지만 변경하면 됨. 그 이후의 로직을 따로 가지고 가도록 중간에서 하나의 객체를 더 만들어 처리할 수 있도록 함!

2️⃣ 예시2) 스키마 이름 바꾸는 일 password-> pwd 컬럼명을 바꾸었을 때 프론트엔드까지 바꿔야하는 상황 발생. 중간에 끊어서 프론트엔드에서는 여전히 같은 컬럼명 사용 가능하고, 중간에 전환 로직을 추가하는 것이 좋음!

결론

** 아래의 예시에서 단일 책임의 원칙이 깨지지 않게 하기 위해 DTO가 필요하다!** 단일 책임 원칙: 수정은 _하나의 actor_만 존재해야 함!

1) client 무슨 일 생겼을 때 -> DB까지 db에 그대로 저장될 데이터는 아님 필드를 추가해도 되니? 2) DB에 무슨 일 생겼을 때 -> client가 알아야 해? (DB 컬럼 이름이 바뀌면, 클라이언트 호출도 바껴야 함?) ➡️ 데이터를 옮기는 객체가 하나일 경우 여러 계층에서 그 객체에 수정을 가하면 단일 책임 원칙이 바로 깨진다!

정리해서..DTO(Data Transfer Object) 특징은?

• 데이터 전송용 객체 = 엔티티(Entity)의 사본

• setter: 되도록이면 사용하지 말자! setter 사용시 언제든 누구나 값을 변경할 수 있어 DB의 사용이유인 '무결성'을 위반하기때문!

  • DB -> (Object: setter 포함)->Client
  • DB 쓰는 이유? 보안, 무결성

• Q. setter를 DTO가 절대 가지면 안될까요? NOPE! 절대는 NOPE! 그럼 언제써야할까? update할 때 사용가능!!

Entity(이자 Domain Object인 친구)

• 데이터 원본 from DB
• DB로 들어갈/연산이 끝난 (=원본이 될 ) 객체 *강형욱: DTO, 박완규: Entity *

- JPA > jdbc Entity..? 왜...?

✅ 그렇다면 DTO <-> Entity 어디서 바뀌는 걸까?

• 원본 이름 : 엔터티
• 전송일때 DTO
• Client->Controller->Service->Repository->DB
• DB->Repository->Service->Controller->Client
• 입장1: controller에서 변환되는거야! : request, response를 받는 역할인데 연산을 왜해? 서비스에서 dto로 바꾼다는 건 클라이언트꺼까지 고민해야한다는 건데 왜 service에서 클라이언트를 굳이 고민해야해?
• 입장2: service에서 변환되는 거야! :DTO와 Entity를 변환하는 것은 연산이므로 이는 Service의 책임이라고 생각해!
• 입장3: repository에서 변환되는 거야! : 이동할때 dto사용하는거라며!! 그럼 repository로 부터 나온 결과를 service에 전달할때도 필요하잖아~!

controller, service, repository 모두 다 가능!

🌟 미리보기

• A service->B Service ❌: 의존성 존재, 서로가 없으면 못 돌아간다는 것! 잘못된 설계!
• A controller-> B Service 🅾️
• A Service-> B repository 🅾️
• A controller -> B controller ❌ ** 같은 계층끼리 사용하는 것: 서로 의존하는 것 다른 계층끼리 사용하는 것: 독립/모듈화가 잘 되어있는 것**