'5월 15일' 푸른 달 셋째 주 수요일의 기록 [TIL]

📑오늘 학습한 내용

🧩오늘의 알고리즘 : 서울에서 김서방 찾기 🧩

문제 : String형 배열 seoul의 element중 "Kim"의 위치 x를 찾아, "김서방은 x에 있다"는 String을 반환하는 함수, solution을 완성하세요. seoul에 "Kim"은 오직 한 번만 나타나며 잘못된 값이 입력되는 경우는 없습니다.

제한 사항

• seoul은 길이 1 이상, 1000 이하인 배열입니다.
• seoul의 원소는 길이 1 이상, 20 이하인 문자열입니다.
• "Kim"은 반드시 seoul 안에 포함되어 있습니다.

class Solution {
    public String solution(String[] seoul) {
        int i = 0;
        for(String name : seoul) {
            if(name.equals("Kim")){
                break;
            }
            i++;
        }
        return "김서방은 " + i +"에 있다"; 
    }
}

띄어 쓰기 똑바로 해야 함.
return "김서방은" + i +"에 있다"; ⇒ 오답
return "김서방은 " + i +"에 있다"; ⇒ 정답

🧩 오늘의 SQL : 카테고리 별 상품 개수 구하기 🧩

문제 : PRODUCT 테이블에서 상품 카테고리 코드(PRODUCT_CODE 앞 2자리) 별 상품 개수를 출력하는 SQL문을 작성해주세요. 결과는 상품 카테고리 코드를 기준으로 오름차순 정렬해주세요.

SELECT LEFT (PRODUCT_CODE, 2) AS CATEGORY, COUNT(PRODUCT_ID) AS PRODUCRS
FROM PRODUCT
GROUP BY CATEGORY

🪴Spring 개인 과제를 들어가기 전..

Client <-dto-> controller(web) - service - repository(JPA) <-domain(entity)-> DB

MVC 패턴

• MVC 패턴은 Model-View-Controller의 약자

• 개발을 할 때 위의 3가지 형태로 역할을 나누어 개발하는 방법

  • Model
    • 어플리케이션이 무엇을 할 것인지 정의하는 부분
    • DB와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룸
  • View
    • 사용자에게 시각적으로 보여주는 부분
  • Controller
    • Model이 데이터를 어떻게 처리할지 알려주는 역할
    • 사용자에 의해 클라이언트가 보낸 데이터가 있으면 모델을 호출하기 전에 적절히 가공하고 모델을 호출함
    • 이후 모델이 업무 수행을 완료하면 그 결과를 가지고 View에게 전달하는 역할

• 위의 3가지 형태로 분리해 각자의 역할에 집중할 수 있게 개발하여 유지보수성, 애플리케이션의 확작성이 증가하고 중복코딩 문제점을 해결할 수 있어 MVC 패턴을 사용

Controller

• 사용자의 요청이 진입하는 지점
• 요청에 따라 어떤 처리를 할지 결정을 Service에 넘겨 줌
• Service에서 실질적으로 처리한 내용을 View에게 넘겨줌
• Controller 사용 이유
  • 대규모 서비스가 있을 때 여러 종류의 서비스를 한 클래스에서 처리하는 대신 Controller라는 중간 제어자를 만들어 A 서비스에 대한 것은 A-Controller가 맡고, B 서비스는 B-Controller가 맡는 식으로 역할에 따라 설계하고 코딩하여 개발 비용과 유지보수비용을 줄일 수 있기 때문에 Controller를 사용함

Controller 사용법

• 스프링에서 컨트롤러를 지정해주기 위한 어노테이션 두 가지 :
  @Controller와 @RestController

1. @Controller
   • 전통적인 Spring MVC의 컨트롤러
   • 주로 View를 반환하기 위해 사용
   • @ResponseBody 어노테이션과 같이 사용하면 RestController와 똑같은 기능을 수행할 수 있음
2. @RestController
   • Controller에서 @ResponseBody 어노테이션이 붙은 효과
   • 주용도는 JSON/XML형태로 객체 데이터 반환을 목적으로 함

Entity

• 데이터베이스에 쓰일 필드와 여러 엔티디간 연관관계를 정의
• 아래 표에서 세로의 열 부분이 Column, 가로의 행 부분이 Entity 객체, 테이블 전체가 Entity임

컬럼 1	컬럼 2	컬럼 3	컬럼 4
엔티티 객체 1-1	엔티티 객체 1-2	엔티티 객체 1-3	엔티티 객체 1-4
엔티티 객체 2-1	엔티티 객체 2-2	엔티티 객체 2-3	엔티티 객체 2-4

• 필드 : 엔티티의 각 Column
  • java private Long column1

Service

↓ Service를 이해하기 위한 큰 틀
1. Client가 Request를 보냄(Ajax, Axios, fetch등..)
2. Request URL에 알맞은 Controller가 수신 받음 (@Controller ,@RestController)
3. Controller 는 넘어온 요청을 처리하기 위해 Service 를 호출
4. Service는 알맞은 정보를 가공하여 Controller에게 데이터를 넘김
5. Controller 는 Service 의 결과물을 Client 에게 전달

Service가 알맞은 정보를 가공하는 과정을 '비즈니스 로직을 수행한다.' 라고 함
Service가 비즈니스 로직을 수행하고 데이터베이스에 접근하는 DAO를 이용해서 결과값을 받아 옴

DAO

• MySql 서버에 접근하여 SQL문을 실행할 수 있는 객체
  • 단순하게 페이지를 불러오고 DB정보를 한 번에 불러오는 간단한 프로젝트의 경우 Service와 DAO는 차이가 거의 없다고 볼 수 있음

DAO & JPA

• pring Data JPA는 매우 적은 코드로 DAO를 구현할 수 있도록 해줌

• 인터페이스를 만드는 것 만으로도 Entity (@Entity)클래스에 대한 insert, Update, Delete, Select 를 실행할 수 있도록 해줌

• 인터페이스에 메소드를 선언하는 것 만으로 라이트한 쿼리를 수행하는 코드를 만드는것과 동등한 작업을 수행

• 하지만 JPA가 만들 수 있는 코드는 매우 가볍고 쉬운 쿼리를 대체하는 것이라서 복잡도가 높아지면 사용하기가 매우 어려움

  • 그래서 JPA를 깊게 공부를 해서 JPA로 복잡도가 높은 쿼리를 짜거나 아니면 복잡도가 높은 곳은 DAO로 같이 사용

Repository

• Entity에 의해 생성된 DB에 접근하는 메서드 들을 사용하기 위한 인터페이스
• @Entity라는 어노테이션으로 데이터베이스 구조를 만들었다면 여기에 CRUD를 어떻게 할 것인지 정의해주는 계층
• JpaRepository를 상속받도록 함으로써 기본적인 동작이 모두 가능해짐
• paRepository는 어떤 엔티티를 메서드의 대상으로 할지를 다음 키워드로 지정
  • JpaRepository<대상으로 지정할 엔티티, 해당 엔티티의 PK의 타입>.

Client <-dto-> controller(web) - service - repository(JPA) <-domain(entity)-> DB

@ 어노테이션

• @Entity : 클래스 위에 선언하여 이 클래스가 엔티티임을 알려줌, JPA에서 정의된 필드들을 바탕으로 데이터베이스에 테이블을 만들어줌
• @Builder : 해당 클래스에 해당하는 엔티티 객체를 만들 때 빌더 패턴을 이용해서 만들 수 있도록 지정해주는 어노테이션, 나중에 다른 곳에서 Board.builder(). {여러가지 필드의 초기값 선언 }. build() 형태로 객체를 만들 수 있음
• @AllArgsConstructor : 선언된 모든 필드를 파라미터로 갖는 생성자를 자동으로 만들어줌
• @NoArgsConstructor : 파라미터가 아예없는 기본생성자를 자동으로 만들어줌
• @Getter : 각 필드값을 조회할 수 있는 getter를 자동으로 생성
  • 예를들어 다른 파일에서 Board 객체의 title값을 얻고 싶다면 getTitle() 메서드를 정의해서 해당 객체의 title값을 얻어오게 되는데, 해당 메서드를 굳이 작성하지 않아도 자동으로 생성해 줌.
• @ToString : 해당 클래스에 선언된 필드들을 모두 출력할 수 있는 toString 메서드를 자동으로 생성할 수 있도록 해줌
• @Id : 해당 엔티티의 주요 키(Primary Key, PK)가 될 값을 지정
• @GeneratedValue : 이 PK가 자동으로 1씩 증가하는 형태로 생성될지 등을 결정
• @ManyToOne : 해당 엔티티와 다른 엔티티를 관계짓고 싶을 때 쓰는 어노테이션

DTO

• DTO(Data Transfer Object)란 계층간 데이터 교환을 위해 사용하는 객체(Java Beans)
• DTO는 클라이언트 요청에 포함된 데이터를 담아 서버 측에 전달하고, 서버 측의 응답 데이터를 담아 클라이언트에 전달하는 계층간 전달자 역할
• 계층간 데이터 교환을 위한 객체(Java Beans)
• DB에서 데이터를 얻어 Service나 Controller 등으로부터 보낼 때 사용하는 객체
• 로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖지만 DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없고 생성자에서 값을 할당함

  • Request와 Response용 DTO는 View를 위한 클래스

• 자주 변경이 필요한 클래스
• Presentation Model
• toEntity() 메서드를 통해서 DTO에서 필요한 부분을 이용하여 Entity로 만듦
• 또한 Controller Layer에서 Response DTO 형태로 Client에 전달

💡 Reference

Controller, Service, Repository 가 무엇일까?
스프링 부트 : 기본 개념 1) Entity, Repository 개념
패키지 구조, DB,DTO