개발자되기 프로젝트

1. 구현 기능 상품 등록 상품 목록 조회 상품 수정 2. 개발 순서 상품 엔티티 개발, 비느지느 로직 추가 상품 repository 상품 service 상품 기능 test 3. Item class 개발 객체 지향 관점으로는 데이터를 가지고 있는 곳 에서 business method가 있는 것이 좋다. 따라서 도메인 주도 설계 시 엔티티 자체가 해결할 수 있는 것은엔티티 안에 메서드를 만듦. 이 때 Setter로 변경하는 것이 아니라 특정 메서드(로직)을 통해 값을 변경해야 한다. 예제의 경우 주문에 따라 재고 수량(stockQuantity)가 변경이된다. stockQuantity는 Item에서 가지고 있다. 따라서 stockQuantity가 변경되는 로직은 Item에 추가하자. Item class - ..

1. 엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있으면 변경 포인트가 많아서 유지보수가 어려워진다.. 2. 모든 연관관계는 지연로딩으로 설정! 엄!청!중!요! EAGER타입은 예측이 어렵고, 어떤 SQL이 실행되는지 추적하기 어렵다. - 특히 JPQ을 실행할 때 N+1 이슈가 발생한다. - 만약 A와 B가 일대다 관계인데, EAGER 타입이다? - A불러오는 쿼리 실행하고 n개의 B를 불러오는 쿼리 바로 실행됨 ㄷㄷ JPA Fetch type, N + 1 이슈 1. Fetch Type이란? Entity 를 조회할 경우 해당 Entity와 연관관계에 있는 Entity를 어떻게 가져올 것인지 설정하는 값이다. - 연관 관계에 있는 Entity 를 모두 가져온다 → Eager - 연..

1. 엔티티 클래스 개발 시 주의사항(Getter, Setter), 참고 이론적으로 Getter, Setter 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적. Getter의 경우 모두 열어두는 것이 편리하다. Getter는 아무리 호출해도 호출 해도 값이 변하거나 무슨 일이 일어나지 않는다. 하지만 Setter를 호출하면 데이터가 변한다. Setter를 막 열어두면 엔티티가 왜? 변경되는지 추적하기 어려움 그래서 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확 하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다 테이블은 관례상 테이블명+id로 사용함. 그래서 column(name="필드명_id")로 했음. 2. 일대다, 다대일 many측에 FK가 있음. many..

1. 도메인 모델 회원과 주문의 관계 : 1 대 N 주문과 배송의 관계 : 1 대 1 카테고리와 상품의 관계 : N 대 N 주문과 상품의 관계 : N 대 N - 그러나 다대다 관계는 관계형 DB, entity에서도 사용하지 않음 - 1 대 N 관계로 풀기 위한 중간에 주문 상품이 존재. 상품을 도서 음반 영화 각각 상속 받음. 2. 엔티티 분석 Member : id(PK), 이름, 입베디드 타입인 Address, Order List를 가진다. Order : 한 번 주문 시 여러 상품 주문 가능함. 따라서 Order와 OrderItem을 일대다 관계. Order는 Item을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태를 가지고 있다. 주문 상태는 열거형을 사용 --> 주문(Order), 취소(CANC..

1. BeanFactory 스프링 컨테이너의 최상위 인터페이스 = 가장 기초적인 스프링 컨테이너의 역할? 스프링 빈을 관리하고 조회하는 역할 getBean() 제공 2. ApplicationContext BeanFactory기능을 모두 상속받음 그럼 BeanFactory랑 무슨 차인데?? BeanFactory에 부가기능을 더해줘! 3. MessageSource 메세지소스를 활용한 국제화 기능 예를 들어서 한국에서 들어오면 한국어, 영어권에서 들어오면 영어로 ㅋㅋㅋ 4. EnviromentCable 환경 변수 개발 환경은 크게 3가지 - 로컬 - 테스트 서버(개발) - 운영 - 스테이지 : 운영과 비슷한 환경 로컬, 개발, 운영 등을 구분해서 처리 5. ResourceLoader 편리한 리소스 조회 파일 ..