Daily Study : 1

IssuedAt : 25 - 09 - 16 (화) 

Daily Study 1 

---

회원별 상품 API 구현 

 

- 엔티티 관계 설정하는 부분에 있어서 회원 객체에서 상품 객체를 조회하는 경우가 없을까 ? 

예를 들면 마이페이지 에서 관심 상품으로 등록한 목록을 가져오려고 할 때 조회해야 하지 않을까 라는 생각이 드는데.. 

어떤 한 클라이언트가 주문, 관심 상품 등록한 목록을 보고 싶다면 이 것이 회원 객체에서 상품 객체를 조회하는 것이지 않을까 ? 

 

 

📒 반은 맞고 반은 틀린 생각 같다.. 

우선 쇼핑몰 같은 도메인에서는 회원 객체가 상품 객체를 직접적으로 조회하는 경우는 일반적으로 없다고 한다. 

중간 엔티티 객체를 사용하여 조회를 한다고 하는데, 

회원과 상품은 서로 독립적인 엔티티인데 회원이 상품을 소유 하는 관계가 아니라 별도의 비즈니스 로직을 통해 연결된다고 한다.

Member -> Order -> OrderItem -> Product
Member -> Cart -> CartItem -> Product

 

🔎 예외는 존재한다 !! 

판매자 역할의 회원이 자신의 상품을 관리하는 경우에는 직접적인 소유 관계가 있어서 조회할 수 있지만, 

성능과 유지보수를 고려해 서비스 레이어에서 처리하는 것이 더 좋은 설계라고 한다... 

---

상품 페이징 및 정렬

 

- 더미 데이터, 테스트 데이터를 프로젝트에 넣어주기 위한 방법으로 ApplicationRunner 를 사용해보았다. 

ApplicationRunner 인터페이스를 구현 하면 스프링이 처음에 시작 할 때 호출이 된다고 한다. 

궁금해서 찾아보니 아래와 같은 장단점이 있다고 한다. 

 

📒 ApplicationRunner 장단점 

(장점) 

1. 애플리케이션 컨텍스트가 완전히 로드된 후 실행되어 안전하다. 

2. 여러 개 구현 시 @Order로 실행 순서 제어가 가능하다. 

 

(단점)

1. 매번 애플리케이션 시작 시마다 실행되어 중복 데이터 삽입이 될 수 있다.

2. 중복 데이터 삽입을 방지하는 로직이 필요하다.

3. 예외 발생 시 애플리케이션 시작이 실패할 수 있다. 

 

겉보기에는 편해보이지만 단점이 조금 더 큰 거 같은데.. 

코드 사용한 이후에는 오류가 난다고 모두 주석으로 처리를 하고 마무리 했지만 데이터들을 날리고 다시 데이터를 집어 넣을 때 

이 클래스 파일을 찾고~ 주석을 풀고 실행 시킨 이후 다시 주석을 하는 게 귀찮을 거 같다.. 

---

상품 폴더 설계 

 

- 엔티티의 관계에서 다대일인 경우 다에 해당하는 쪽이 외래키 주인 역할을 한다. 

엔티티 관계, 연관관계 설정 하는 공부를 하면서 항상 "엔티티의 관계에서 다대일인 경우 다에 해당하는 쪽이 외래키 주인" 이라는 말을 들었다. 

오늘 블로그 작성을 시작하면서 이 말도 궁금해졌다 "왜 항상 다에 해당하는 쪽이 외래키 주인 역할을 하는 것일까 ?"

 

📒 다대일 관계에서 다에 해당하는 쪽에 외래키 주인을 주는 이유 

1. 데이터베이스 설계 원칙

2. 성능상의 이유 

3. 업데이트 효율성 

등의 이유가 있는데 다 중요한 ..이유들 밖에 없다 .. 그리고 다대일 관계에서는 "다"쪽이 외래키 주인이 되는 것이 표준 이라고 한다. 

이는 데이터베이스에서 정규화, 성능, 그리고 직관성 모든 면에서 장점이 있다고 한다 ! 

특별한 이유가 없다면 이 패턴을 따라가도록 .. 

 

📒 연관관계 다대일에서 단방향 ? 양방향 ?? 

지금까지 공부하면서 단방향과 양방향 조회하는 것에 있어서 그냥 뇌 빼고 수업만 들은거 같아서 정리하려고 한다.. 

다대일 관계에서 외래키의 주인은 "다"에 해당한다. 

class Product {
	
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    private Category category;

}

 

단방향 조회시에는 "일"에 해당하는 엔티티에는 "다"에 정보가 필요없다. 

class Category{

	private Long id;
}

 

양방향 조회시에는 "일"에 해당하는 엔티티에도 반드시 "다"에 해당하는 엔티티 정보를 작성해야한다. 

작성할 때는 OneToMany 키워드와, mappedBy 키워드가 중요하다 

class Category{

	private Long id;
    
    @OneToMany(mappedBy = "category")
    private List<Product> products = new ArrayList<>();
}

---

폴더 생성 및 조회 구현 

 

- RequestDto , ResponseDto에 대한 개념을 다시 잡고 가야할 거 같다 .. 

 

📒 RequestDto랑 ResponseDto 

먼저 RequestDto는 클라이언트에서 서버로 데이터를 전송할 때 사용한다. 

클라이언트가 HTTP 요청을 보낸 본문 Request Body를 받기 위한 객체이고, 

서버에서 데이터를 받으면서 입력값 검증 Validation 을 적용한다. 

 

ResponseDto는 서버에서 클라이언트로 데이터를 응답할 때 사용한다. 

HTTP 응답 본문 Response Body 로 보낼 데이터 정의하며, 

클라이언트가 필요한 데이터만 선별해서 전송한다. 

이때 중요한 !! 비밀번호등 민감한 정보는 보내면 안된다 !! 

 

🔎 Dto객체를 사용하는 이유는 

계층 분리하며, 보안 적인 요소와 API 스펙 명확화를 위해서이다. 

그리고 검증 로직도 분리할 수 있다. Entity를 직접 노출하지 않고 DTO를 사용하는 것이 좋은 패턴이라고 한다. 

 

- 쿼리 공부 ...

Repository를 사용하면서 제공되는 기본 메서드 말고 새로 정의해야 하는 메서드들이 있다.. 

In 존재에 대해서 까먹고 있다가 날벼락을 맞은 느낌이랄까.. 쿼리 공부도 열심히 해야겠다 ..

List<Folder> findAllByUserAndNameIn(User user, List<String> folderNames);

SQL 쿼리를 예상 해보는 ? 맞춰보는 연습을 해야할거같다.. 

select * from folder where user_id = ? and name in (); 

 

 

 

기타 ... 엔티티 클래스 객체 하나는 데이터베이스에서는 한줄이 된다 !! 

---

그레이들(Gradle)이란 무엇일까 ?

(복습 #2) 

 

그레이들은 빌드 자동화 시스템이다. 

자바의 소스코드를 실행 가능한 jar 파일로 편하게 변환 해준다. 

---

서버란 무엇일까

(복습 #2)

 

API는 하나의 약속 

API 테이블은 API 들을 한눈에 확인하고 협업하는 개발자들과 소통하기 위해 작성하는 일종의 표 

name	method	URL	설명
인사	GET	/api/hello	Hello World! 출력