SOUT✅

SQL 중심적인 개발의 문제점 애플리케이션을 개발할 때는 보통 객체 지향 언어로 개발한다. 데이터베이스는 대부분 관계형 DB를 사용한다. → 지금 시대는 객체를 관계형 DB에 관리함. 무한 반복되고, 지루한 코드. CRUD만 무한 반복해서 개발함. 중간에 필드가 수정되는 경우, 모든 SQL문을 수정해야함. 패러다임의 불일치: 객체 vs 관계형 데이터베이스 객체(Object) → RDB, NoSQL, File, OODB 등 다양한 형태로 저장할 수 있음. 하지만 현실적인 대안은 RDB를 선택한다. 객체 → SQL → RDB: 이런 과정으로 RDB에 저장한다. 객체와 관계형 데이터베이스의 차이 상속 데이터베이스 테이블에는 상속이 없다 → 슈퍼타입(ex. Item), 서브타입(ex. Album) 관계로 설계함..

* record: 특정 값 타입을 담는데 특화됨. DTO로 쓰기 좋음 보통 보일러 플레이트 코드는 lombok을 사용하여 중복된 코드를 줄인다. public record Example(String name, String series) {} 컴파일러는 헤더를 통해 내부 필드를 추측한다. -> getter, setter, toString, equals, hashCode를 선언하지 않아도 자동으로 구현된다. getter를 사용할 때: getName()이 아니라, name()과 같이 사용한다. 그 외의 특징 - 불변 객체(final)이고, 한번 값이 정해지면 값을 변경할 수 없다. - 각 필드는 private final으로 정의된다. - 자동으로 생성된 메소드는 @Override로 수정할 수 있다. - 컴팩트 ..

간단한 주문 조회 API: Order + Member + Delivery 테이블 조회 (_ToMany 객체 조회) V1: 엔티티를 직접 노출 @RestController @RequiredArgsConstructor public class OrderSimpleApiController { private final OrderRepository orderRepository; @GetMapping("api/v1/simple-orders") public List ordersV1() { List all = orderRepository.findAll(new OrderSearch()); return all; } } 무한루프에 빠진다: Order 조회 → Order의 Member 조회 → Order의 Member의 Ord..

회원 등록 API // v1 code @RestController // @Controller + @ResponseBody @RequiredArgsConstructor public class MemberApiController { private final MemberService memberService; @PostMapping("/api/v1/members") public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) { /* @RequestBody: Json으로 온 Body를 Member으로 바꿔줌 @Valid: 회원의 Validation 진행 */ Long id = memberService.join(member); retur..

홈 화면과 레이아웃 HomeController 클래스 생성 @Controller @Slf4j // 로그 출력 public class HomeController { @RequestMapping("/") public String home() { log.info("home controller"); return "home"; // templates/home.html 파일을 리턴 } } 회원 등록 회원 가입: /members/new controller/MemberForm class @Getter @Setter public class MemberForm { @NotEmpty(message = "회원 이름은 필수 입니다") private String name; private String city; private St..

상품 주문 → 재고도 함께 감소 주문 내역 조회 주문 취소 → 재고 다시 원상복귀 주문, 주문상품 엔티티 개발 주문 생성 메서드: Delivery status 설정, 주문자 및 배송, 주문일 등 설정 비즈니스 로직: 주문 취소 메서드(Delivery status 변경, 주문한 수량만큼 재고 증가) 조회 로직: 전체 주문 가격 조회: 각 orderItem의 totalPrice를 더한 값을 반환 주문아이템 생성 메서드: item, orderPrice, count 설정 및 재고 감소 비즈니스 로직: 주문 취소했을 때 주문 수량만큼 재고 증가 조회 로직: 주문 상품 전체 가격 조회 주문 리포지토리 개발 @Repository @RequiredArgsConstructor public class OrderReposi..

상품 등록 상품 목록 조회 상품 수정 상품 엔티티 개발(비즈니스 로직 추가) 재고를 늘리고 줄이는 비즈니스 로직 : Item 엔티티 안의 stockQuantity에 대한 로직이므로 엔티티에 비즈니스 로직을 추가하는 것이 좋다. (service에서 건들이면 객체를 가져와서 수정해야함. 번거로움) @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) // 한 테이블에 몰아넣기 @DiscriminatorColumn(name = "dtype") @Getter @Setter public abstract class Item { @Id @GeneratedValue @Column(name = "item_id") private Long id; private Str..

회원 리포지토리 개발 @Repository // @Repository: Component scan으로 Spring bean 자동 등록 public class MemberRepository { // @PersistenceContext: Spring이 EntityManager 생성 후 주입 @PersistenceContext private EntityManager em; public void save(Member member) { em.persist(member); // member 저장 } public Member findOne(Long id) { return em.find(Member.class, id); } public List findAll() { return em.createQuery("select..

예제 엔티티/DB 테이블 JPA 다:다 가능하지만 사용하면 안 된다! (예시: Category-Item) Order도 Member를 가지고, Member도 Order를 가지고 있다(양방향) → 설계상 추천하지 않는다. (예제니까 그냥 양방향으로 간다) Item을 상속하는 Album, Book, Movie → 한 테이블에 그냥 다 넣어버림 Order 예약어가 있어서 관례상 Orders로 사용한다 엔티티에서는 List를 사용 → 관계형 데이터베이스에서는 중간 테이블이 필요하다(CATEGORY_ITEM) 📌 엔티티 → 관계형DB와 매핑되는 자바 객체 테이블 → 실제 DB에 들어가는 테이블 Member 엔티티 @Entity @Getter @Setter public class Member { @Id @Genera..

JPA 강의에서는 org.junit.Test 라이브러리를 사용하여 Exception 테스트를 할 때 @Test(expected = NotEnoughStockException.class) expected를 사용하여 예외 처리를 했다. 하지만 JUnit5에서는 org.junit.Test를 사용하는 경우 InitializationError가 발생하였고, org.junit.jupiter.api.Test 라이브러리에서는 다음과 같이 expected가 허용되지 않았다. 검색 결과, JUnit5에서는 예외 테스트를 다음과 같이 assertThrows를 사용하여 테스트를 진행해야 한다. @Test public void 메소드이름() { // ...테스트 로직 assertThrows(Exception클래스이름, () -..

Provider란 Dependency Lookup을 해야할 때 사용할 수 있는 방법이다. ObjectProvider, Provider(JSR) 등이 있다. Spring에서 Provider를 사용하는 이유 컨테이너가 의존성을 넣어주는(알맞은 빈을 찾아 넣어주는) 것이 아니라, 개발자가 컨테이너에서 알맞은 빈을 찾아야 할 때 Provider를 사용한다. 강의에서는 '싱글톤 빈에서 프로토타입 빈을 사용할 때' Provider를 사용한다고 소개했지만 실무에서 이런 경우는 잘 없다고 한다. (대부분 싱글톤으로 해결 가능) 핵심은 내가 필요할 때 꺼내 사용할 수 있다는 것이다. request 스코프 예제에서: 1. LogDemoController는 의존관계 주입 과정에서 MyLogger가 필요한 상황. 2. MyL..

Spring 자바 어플리케이션 개발에 사용되는 백엔 프레임워크이다. JSP, Hibernate, JUnit 등 다양한 프레임워크 지원을 하는, 프레임워크의 프레임워크라 볼 수 있다. - 제공 기능: DI(의존성 주입), IoC, AOP Spring Boot REST API 개발에 사용되며, 스프링 프레임워크 위에서 실행된다. 스프링 사용을 자동화하여 사용자가 편리하고 빠르 스프링을 활용할 수 있도록 한다. - 제공 기능: AutoConfiguration 기능, Tomcat과 같은 서버 제공