개발 성장 일기 :)

스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 ac.getBean(빈이름, 타입) ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 NoSuchBeanDefinitionException: No bean named 'xxxxx' available

1. 모든 빈 출력하기 실행하면 스프링에 등록된 모든 빈 정보를 출력할 수 있다. ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다. ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회한다. 2. 애플리케이션 빈 출력하기 스프링이 내부에서 사용하는 빈은 제외하고, 내가 등록한 빈만 출력해보자. 스프링이 내부에서 사용하는 빈은 getRole() 로 구분할 수 있다. ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈 ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

1. 새로운 할인 정책 추가, 문제점 발생 - 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없다. 새로운 할인 정책 적용과 문제점 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체(OrderServiceImpl) 도 함께 변경해야한다. -> OCP위반 : 지금 코드는 기능을 변경하면, 클라이언트 코드를 변경해야 한다. 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy 뿐만 아니라, 구체 클래스인 FixDiscountPolicy 도 함께 의존 -> DIP 위반 ( DIP: 의존관계 역전 원칙 = 추상화에 의존하되, 구체화에 의존하지 말것) 2. 관심사의 분리 1. AppConfig 에서 실제 동작에 필요한 구현객체를 생..

일반적인 웹 애플리케이션 계층 구조 다시한번 상기하기 위해서..! Controller -> Service -> Repository -> DB * 개발 순서 : 1) 엔티티 개발 2) 리포지토리 개발 3) 서비스 개발 4) 테스트 5) 컨트롤러 개발 6) 웹 계층 적용 1. Domain - Item.java - Book.java Item 은 추상화 객체이며, 해당 프로젝트에서만 Book 만 사용하는것으로 개발. 2. Repository - ItemRepository.java @Repository : 스프링 빈으로 등록, JPA 예외를 스프링 기반 예외로 예외 변환 @PersistenceContext : 엔티티 메니저( EntityManager ) 주입 @PersistenceUnit : 엔티티 메니터 팩토리..

1. Bootstrap 다운받기 https://getbootstrap.com Bootstrap The most popular HTML, CSS, and JS library in the world. getbootstrap.com 파일 다운로드해서, 프로젝트의 resources> static 폴더 밑에 복사 붙여넣기 해주기 복사붙이기 하면 바로 적용안되는데, rebuild 하거나 동기화시켜주고 다시 서버 동작시키면 된다. ( + 부트스크랩 버전이 안맞아서 잘 실행이 안됐는데, 질문을 보니 나같은 사람이 많아서 어떤 분이 해결방법 알려주심.) 오.. Bootstrap 다운받지 않고, CDN 이용해서 하는 방법이라고 합니다 :0 header.html 에 아래 소스 추가해주면 실행되더라구요 👍🏻 ( 똑똑이들 많다..

1. 주문, 주문상품 엔티티 개발 : Order / OrderItem 1) Order 클래스에 추가하기 1. 생성메서드 : createOrder ( Member, Delivery, OrderItem...) 2. 주문취소메서드 : cancel() 이미 배송완료된 상태이면, 취소불가 OrderStatus 취소로 변경 OrderItem에서 cancel호출 : 재고수량 원복하는 함수 3. 조회로직 추가 : getTotalPrice() 아이템 가격 * 아이템 갯수 반환 2) OrderItem 클래스에 추가하기 1. 생성메서드 : createOrderItem ( Item, orderPrice, count) 생성 시, 재고에서 주문수량만큼 차감하기 : item.removeStock 2. 비즈니스 로직 : cancel..

1. 회원 Repository 개발 - repository > MemberRepository.class 생성 - JPA를 사용하기 위한 EntityManager - save() - findOne(Long id) - findAll() - findByName(String name) 2. 회원 서비스 개발 - service > MemberService.class 생성 @Autowired MemberRepository 변수에 @Autowired를 지정하게 되면, 테스트코드 작성할때 수정이 어려움. -> 생성자에 Autowired 에노테이션 쓰면 편함 -> Lombok 의 @RequiredArgsConstuctor 사용하면 (final이 붙은) memberRepository에 해당하는 생성자만 만들고, 생성자도 ..

애플리케이션 아키텍처 - Controller - Service - Repository - Domain 계층형 구조 사용 controller, web : 웹 계층 service : 비즈니스 로직, 트랜잭션 처리 repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용 domain : 엔티티가 모여 있는 계층, 모든 계층에서 사용 패키지 구조 jpabook.jpashop domain exception repository service web * 개발순서: 1. 도메인 -> 서비스, 리포지토리를 개발 하고 2. 테이스 케이스 작성해서 검증 3. 마지막에 컨트롤러 통해서 웹 계층 적용 도메인-> 서비스,리포지토리 -> 테스트케이스 -> 컨트롤러 -> 웹 계층

스프링 컨테이너 ApplicationContext 를 스프링 컨테이너라 한다. 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다. 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다. 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService ) 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테..

1. 제어의 역전 IoC (Inversion of Control) 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다. 그리고 AppCon..