WebMaster

@Repositoy = 스프링 부트 애플리케이션 같은 경우 @SpringBootApplication 이 있는 class을 하위 패키지를 자동으로 컴포넌트 스캔하며 빈에 등록하여 주는데 Repository 같은 경우 내부에 @Component 어노테이션이 숨겨져 있다. EmtityManager = JPA가 등록시켜준 EntityManager를 가지고 오기 위해 @PersistenceContext 어노테이션을 사용했다. save 메소드 em.persist(저장 객체) : Database에 저장할 객체를 적어준다. findOne 메서드 id를 가지고 Member를 가지고 온다. em.find(가지 고올 엔티티 클래스, PK) : findAll 메서드 모든 대상을 조회한다. JPQL을 사용한다. select m..

계층형 구조 사용 controller, web: 웹 계층 service: 비즈니스 로직, 트랜잭션 처리 repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용 domain: 엔티티가 모여 있는 계층, 모든 계층에서 사용 controller에서 바로 repository를 접근할 때도 있다(유연한 아키텍처 구조) 패키지 구조 jpabook.jpashop domain exception repository service web 개발 순서: 서비스, 리포지토리 계층을 개발하고, 테스트 케이스를 작성해서 검증, 마지막에 웹 계층 적용

핵심 비즈니스 메서드를 먼저 구현한 뒤, 화면을 연결한다. 구현할 기능 회원 기능 회원 등록 회원 조회 상품 기능 상품 등록 상품 수정 상품 조회 주문 기능 상품 주문 주문 내역 조회 주문 취소 구현하지 않을 기능 로그인과 권한 관리X 파라미터 검증과 예외 처리X 상품은 도서만 사용 카테고리는 사용X 배송 정보는 사용X

엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있다. 변경 포인트가 너무 많아서, 유지보수가 어렵다. 나중에 리펙토링으로 Setter 제거 모든 연관관계는 지연 로딩으로 설정(매우 중요) 즉시 로딩( EAGER )은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. 즉시 로딩 : 연관된 모든 테이블을 다 가지고 온다. 성능상으로 문제가 많다(Lasy로 써서 원하는 것을 실시간으로 선택해서 가지고 와야 한다) N+1 문제 발생 : EAGER로 되어 있을 경우 JPQL로 SELECT 문을 실행했을 때의 결과를 가지고 다시 연관된 테이블을 조회하기 위해 N개의 단건 쿼리가 실행된다 실무에서 모든 연관관계는 지연 로딩( LA..

예제에서는 설명을 쉽게 하기 위해 엔티티 클래스에 Getter, Setter를 모두 열고, 최대한 단순하게 설계 실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천 참고 이론적으로 Getter, Setter 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는 게 가장 이상적이다. 하지만 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로, Getter의 경우 모두 열어두는 것이 편리하다. Getter는 아무리 호출해도 호출하는 것 만으로 어떤 일이 발생하지는 않는다. 하지만 Setter는 문제가 다르다. Setter를 호출하면 데이터가 변한다. Setter를 막 열어두면 가까운 미래에 엔티티에 가 도대 체 왜 변경되는지 추적하기 점점 힘들어진다. 그래서..

요구사항 분석 기능 목록 회원 기능 회원 등록 회원 조회 상품 기능 상품 등록 상품 수정 상품 조회 주문 기능 상품 주문 주문 내역 조회 주문 취소 기타 요구사항 상품은 재고 관리가 필요하다. 상품의 종류는 도서, 음반, 영화가 있다. 상품을 카테고리로 구분할 수 있다 상품 주문 시 배송 정보를 입력할 수 있다. 도메인 모델과 테이블 설계 회원, 주문, 상품의 관계: 회원은 여러 상품을 주문할 수 있다. 그리고 한 번 주문할 때 여러 상품을 선택할 수 있으므로 주문과 상품은 다대다 관계다. 하지만 이런 다대다 관계는 관계형 데이터베이스는 물론이고 엔티 티에서도 거의 사용하지 않는다. 따라서 그림처럼 주문상품이라는 엔티티를 추가해서 다대다 관계를 일대 다, 다대일 관계로 풀어냈다. 상품 분류: 상품은 도서..

의존 라이브러리 확인 ./gradlew dependencies Spring-boot-starter spring-boot-starter-tomcat: 톰캣 (웹서버) spring-webmvc: 스프링 웹 MVC Thymeleaf: 타임리프 템플릿 엔진(View) Spring-boot-starter-data-jpa spring-boot-starter-aop spring-boot-starter-jdbc HikariCP 커넥션 풀 (부트 2.0 기본) hibernate + JPA: 하이버네이트 + JPA spring-data-jpa: 스프링 데이터 JPA spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅 spring-boot spring-core spring-boot-starte..

SpringWeb = 웹 관련 설정 Thymelef = HTML을 서버에서 보여주기 위한 템플릿 Spring Data JPA = JPA를 사용 가능하도록 해주는 라이브러리 H2 Database = H2 DB를 사용 가능하도록 해주는 라이브러리 Lombok = Lombok설정을 사용 가능하도록 해주는 라이브러리 Lombok 세팅 확인 File -> settings -> plugins 의 Lombok plugin 다운로드 Settings -> Annotation Processors의 Enable annotation processing을 체크해 주어야 된다.

AOP: Aspect Oriented Programming 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 분리 AOP 적용하기 AOP가 존재하면 가짜 서비스 프록시를 앞에 새워 둔 뒤, 가짜 프록시가 끝나게 될 때 실제 Service가 실행된다. service가 복제된 빈이라는 걸 알 수 있다.

AOP가 필요한 상황(관점 지향 프로그래밍) 모든 메서드의 호출 시간을 측정하고 싶다면? 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 회원 가입 시간, 회원 조회 시간을 측정하고 싶다면? 만약 모든 로직에 시간 측정을 추가한다면 모든 코드를 수정해야 되기 때문에 시간이 오래 걸린다. 문제 회원가입, 회원 조회에 시간을 측정하는 기능은 핵심 관심 사항이 아니다. 시간을 측정하는 로직은 공통 관심 사항이다. 시간을 측정하는 로직과 핵심 비즈니스의 로직이 섞여서 유지보수가 어렵다. 시간을 측정하는 로직을 별도의 공통 로직으로 만들기 매우 어렵다. 시간을 측정하는 로직을 변경할 때 모든 로직을 찾아가면서 변경해야 한다.