차동민의 험난한 객체지향 여행기

1. 더 개선해보자 앞선 포스팅에서 확인 할 수 있었듯이, 객체의 책임을 분리하여 더 변화와 확장에 유연한 프로그램을 설계할 수 있었다. 하지만 더 개선할 수 있다. package ObjectStudy.reservation; public class Audience { private Bag bag; public Audience(Bag bag) { this.bag = bag; } public Bag getBag() { return bag; } public Long buyTicket(Ticket ticket){ if (bag.hasInvitation()){ bag.setTicket(ticket); return 0L; }else{ bag.minusAmount(ticket.getFee()); bag.setTick..

1. 티켓 판매 애플리케이션 요구사항 : 티켓판매 애플리케이션의 요구사항은 다음과 같다. 이벤트에 당첨된 사람들에게는 초대장을 발송한다. 입장할때 초대장이 있는 사람들은 초대장을 티켓을 교환한다. 초대장이 없는 사람들에게는 티켓을 판매한다 2. 클래스 구조 클래스 다이어 그램은 다음과 같다. Audience는 Bag을 필드로 가지고 있고, Bag은 필드로 Invitation, Ticket을 가지고 있다. TicketSeller는 TicketOffice를 필드로 가지고 있고, TicketOffice는 Ticket을 필드로 가지고 있다. 관객을 입장시키기 위한 Theater의 enter 메서드를 보자 public class Theater { private TicketSeller ticketSeller; pu..

1. 프로젝트 개요 위와 같이 사용자가 숙소를 조회하고 장바구니에 담고 예약을 할 수 있는 숙박 플랫폼을 제작했다. 팀장님이 플래닝포커 방식 등 여러 애자일한 방법들을 많이 도입하셔서 정말 실무에서 개발하는 것과 유사한 방식의 일정관리를 해볼 수 있었다. 정말 시간이 촉박했지만, 1차 2차 스프린트로 나누어서 개발을 했던 것이 야놀자 멘토님게도 좋은 평가를 받아서 좋았다. 2. ERD ERD 설계가 프로젝트에서 가장 힘든 것 중 하나였다. 정말 많이 고민했었고, 정말 많은 수정을 거듭했다. 그 중에서도 객실과 예약이 다대다 관계이기 때문에 가운데에 예약 객실이라는 테이블을 두어 일대다, 다대일 관계로 풀어냈었는데, 이것은 김영한님의 JPA 강좌에서도 나오는 주문 - 상품을 주문상품을 사이에 두어 다대다 ..

첫번째로 인텔리제이에서 Gradle에서 build에 bootJar로 빌드를 하게 되면 왼쪽에 build/libs 디렉토리안에 .SNAPSHOT.jar 파일이 생성된다. 이 jar 파일 안에는 톰캣이 내장되어 있어서 AWS ec2 인스턴스에 이 jar 파일을 넣어주면 배포가 완료된다. 여러 방법이 있지만 그 중에서도 FTP 프로토콜을 사용해서 파일을 쉽게 전송할 수 있는 FileZilla를 사용해서 배포를 진행했다. SFTP 프로토콜을 선택하고 호스트에 EC2 인스턴스의 퍼블릭 IPv4주소를 입력하고 로그온 유형은 비밀번호 묻기나, 인스턴스를 생성했을 때 생성되는 pem 파일 둘 중 하나를 선택하면 된다. 우측에 ec2 인스턴스 내에 app 내에 jar 파일을 생성하며 된다. 서버내에 jar파일을 구동시켜..

1.  Mocking Test를 하는 상황 3차 토이프로젝트를 진행하고, Mockito라는 테스트 도구를 사용하여 Service 계층의 테스트를 진행했다. Mockito를 사용하면 실제 객체를 모방한, Mock 즉 가짜 객체를 생성할 수 있다. 이 가짜 객체를 생성하는 이유는 간단하다. 테스트를 띄울 때 @SpringBootTest 스프링에 등록된 빈이 다 띄워지면서 테스트가 무거워지게 되고 실제 다양한 모듈이 복잡하게 연결된 경우 테스트가 더욱 무거워지게 된다. DB와 연결하지 않고, 즉 스프링을 띄우지 않고 Mock객체의 행동을 미리 정의하여 테스트를 수행하는 것이다. 2. 문제가 되었던 상황 여행을 생성하는 서비스 계층의 로직이다. 먼저 파라미터로 tripCreateRequest를 전달받는다. 1..

1. N+1 문제란? N+1 문제란 한 번의 쿼리를 날렸을 때, 원하지 않은 N개의 쿼리가 추가적으로 실행되는 현상을 뜻한다. 이 N+1문제는 JPA Repository를 사용해 조회(Read)할 때 발생한다. 그리고 1 : N, N : 1 구조에서 나타나는데, 로딩전략에 따라서 다르게 발생한다. 로딩전략이 EAGER, 즉시로딩으로 조회하는 경우 로딩전략이 LAZY, 지연로딩으로 데이터를 가져 온 이후, 연관관계인 하위 엔티티를 다시 조회하는 경우 발생한다. N+1 문제가 발생하는 이유는 JPA Repository로 find시 실행하는 첫 쿼리에서 하위 엔티티까지 한번에 가져오지 않고, 하위 엔티티를 사용할 때 추가로 조회하기 때문에 발생한다고 한다. 그리고 JPQL은 기본적으로 글로벌 Fetch전략을 ..

1. 테이블 구조 현재 위와 같은 구조로 테이블이 정의되어 있다. trip과 itinerary가 1 : N 관계이다. RFP에 나와 있는 trip 조회 API의 요구사항에는 위와 같이 여행을 조회할때 여정의 이름들을 함께 보여주도록 되어 있다. 나는 조금 변형하여 특정 여행을 조회할때 여정 이름들을 함께 보여주도록 구현해보았다. 2. Service 계층 로직 로직이 수행되는 서비스 계층의 메서드이다. 동작하는 방식을 살펴보면 매개변수로 넘어온 tripId로 DB에 여행이 존재하는지를 먼저 확인한 후에, 없다면 예외를 반환한다. (RuntimeException을 던지도록 임시로 구현했다.) 그리고 여행이 존재하면 반환한 trip 엔티티 인스턴스를 DTO로 변환해야 한다. 3. FetchType.EAGER..

이전 포스팅 : 2023.10.31 - [분류 전체보기] - JPA 양방향 매핑 1.  RESTful한 URL 작성 토이프로젝트 RFP에 나와있는 요구사항이다. 여정 정보는 반드시 개별 여행 조회를 통해서 수행해야 한다. 즉 양방향 매핑되어 있는 여행과 여정 연관관계에서 참조의 방향을 강제한 요구사항이다. 나는 이전에 GET http://localhost:8080/itinerary?tripId=3 과 같은 형식의 URL을 사용해서 서버에 조회 요청을 보냈다. 왜냐하면 당연히 도메인을 여행과 여정으로 나눠 놓았고, 도메인이 여정이라면 컨트롤러에서 @RequestMapping("/itinerary")로 식별자를 고정시켜 놓아야 한다고 생각했었다. 멘토님께서는 루트 도메인이 첫번째 식별자로 오는 것이 RES..

1. JPA에서의 양방향 매핑이란 토이 프로젝트로 진행한 '여행과 여정을 기록하는 SNS 서비스' 프로젝트를 마치고, JPA를 능숙하게 다루기 위해서 공부를 하고 있다. 혼동하기 쉬운 개념을 정리하고자 포스팅을 한다. 여행과 여정은 1 : n 관계이다. DB에서는 방향을 설정해주지 않아도 FK를 활용한 조인으로 여행 테이블에서 여정테이블을 접근할 수 있고, 여정 테이블에서 여행테이블에 접근할 수 있다. 하지만 JPA는 ORM(Object Realtionial Mapping) 즉, DB의 테이블을 객체의 클래스로 매핑한 기술이기 때문에 DB와 같은 개념으로 생각하면 안된다. JPA는 양방향 매핑이 DB처럼 양방향 관계가 설정되어 있는 것이 아니다. 아래 그림 처럼 객체의 참조를 통한 2개의 단방향 매핑을 ..

1. 예외처리를 해야하는 이유 스프링을 활용한 프로젝트를 할 때 가장 신경써야 하는 것 중에 하나가 바로 예외처리이다. 예외란 사용자의 잘못된 조작이나 개발자의 코딩 로직의 실수로 인해 발생하는 프로그램 오류를 뜻한다. 예외가 발생해서 프로그램이 종료되면 실제 상용화되어 운영중인 서비스라면 이는 엄청한 피해를 야기할 수도 있다. 적절한 예외처리를 통해서 어떠한 상황에서도 프로그램이 중단되는 일 없이 서비스 되도록 해야한다. 2. 예외를 처리해야 하는 상황 위의 코드를 보면 TripId를 통해 여행 Entity의 내용을 수정하는 서비스 로직이다. 파라미터로 TripId와 수정요청DTO를 받는다. 로직의 첫번째는 파라미터로 전달받은 수정요청DTO를 validation 한다. 그 이후에는 Spring Data..