인프런 스프링 강의 with 김영한

Gradle은 의존성이 있는 라이브러리를 다운로드 받는다.의존성이 있는 라이브러리 확인스프링 부트 라이브러리spring-boot-starter-web \- spring-boot-starter-tomcat: 톰캣 (웹서버) \- spring-webmvc: 스프링 웹

😊들어가면서😊 📌 개발 프로세스 🎯 비즈니스 요구 사항 데이터 : 회원 ID, 이름 기능 : 회원 등록, 조회 아직 데이터 저장소가 선정되지 않음 📌컨트롤러 웹 MVC의 컨트롤러 역할 클라이언트의 요청을 처리하고 응답을 반환하는 역할을 담당한다. 📌서

😀들어가면서😀 📌 스프링 빈을 등록하고 의존관계를 설정하는 방법을 알아보자. 📌 📌 스프링 빈을 등록하고, 의존관계를 설정하기 웹을 만들고 싶어~! -> 컨트롤러를 만들어야 한다. ❗컨트롤러는 서비스를 통해서 !! 👉 멤버컨트롤러가 멤버서비스를 의존한다.

😊들어가면서😊 웹을 만들어보자. 📌 회원 웹 기능 - 홈 화면 추가 📌 회원 웹 기능 - 등록 📌 회원 웹 기능 - 조회 ➕ 웹 MVC란? 애플리케이션을 Model-View-Controller로 나누는 것이다. 🎯 웹 MVC를 만들자. 📌 회원 웹 기

😅들어가면서😅 🎯 프로젝트 생성 ⚠️ 프로젝트 설정의 편리를 위해서 스프링 프로젝트를 생성한다. 대신 의존 ❌ (강의에서는 🔍 (추가로) 스프링 부트 스타터 사이트가 아닌 인텔리제이에서 하는 방법을 공부해보자.

회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다.회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)👉 회원 저장소라는 인터페이스를 사용할 것이다.역할에 대한, 회원저장소에 대한 역할을 메모리 회원 저장소

주문과 할인 정책회원은 상품을 주문할 수 있다.회원 등급에 따라 할인 정책을 적용할 수 있다.할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정

디지몬 OST 버터플라이📌 "소프트웨어는 확장에는 열려있으나 변경에는 닫혀있어야한다."👉 변경 시, 기존 코드를 변경하지 않아도 가능 해야한다.📌 구체화가 아닌, 추상화에 의존해야한다.👉 구현과 역할을 나누고, 역할에 의존하게 해야한다.

👏들어가면서👏 🎯 목표 📌 관심사를 분리하자 🤔 현재상황 구현체에서 다른 구현체를 직접 선언 ⬇️ OrderServiceImpl 코드 내용 ❣️ 관심사를 분리하자 역할에 맡는 구현체를 담당하는 별도의 프로그램 기획자가 필요하다. 📌 config로 D

기존 클라이언트 객체는 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있었다.➡️ SRP 단일 책임 원칙을 따르면서 관심사를 분리함✔️ 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당하게 하여 클라이언트 객체는 실행하는 책임만 담당할 수

프래그램이 제어 흐음을 직접 제어하는 것이 아니라 외부에서 관리하고 제어하는 것을 제어의 역전이라고 한다. appConfig 으로 구현 객체는 자신의 로직만 담당한다.프로그램의 제어 흐음에 대한 권한은 appConfig가 담당한다.프레임워크 : 내가 작성한 코드를 제어

@Configuration 스프링 Configuration 어노테이션@Bean : 스프링 빈으로 등록하는 어노테이션💻 실행화면기존과 동일하고 스프링 빈으로 등록했다는 로그가 뜬다.ApplicationContext 👉 스프링 컨테이너 스프링 컨테이너를 통해서 객체를

스프링 컨테이너를 생성하는 코드ApplicationContext 🟰 스프링 컨테이너ApplicationContext 는 인터페이스로 , 이를 구현한 여러 클래스들이 있다. ex) AnnotationConfigApplicationContext 스프링 컨테이너의 종류 :

내 입술... 따뜻한 커피처럼☕스프링 컨테이너의 최상위 인터페이스다.스프링 빈을 관리하고 조회하는 역할을 담당한다.지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다.➕ getBean() 을 제공한다.ApplicationContext는 B

new AnnotationConfigApplicationContext(AppConfig.class)AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘기면 된다.GenericXmlApplicationContex

스프링 애플리케이션은 보통 웹 애플리케이션이다.웹 애플리케이션은 보통 여러 고객이 동시에 요청을 하게 된다.➡️ 클라이언트가 memberService를 요청할때마다 DI 컨테이너가 새로운 객체를 제공한다.🤔예제💻 실행화면👉 새로운 객체 생성요청을 할 때 마다 객체

ctrl + shift + r

등록할 빈이 수십,수백개가 된다면...?따라서 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.의존관계를 자동으로 주입하는 @Autowired라는 기능도 제공한다.🐸 AutoAppConfigMemoryMemberRepository

컴포넌트 스캔에서 동일한 이름이 있을 경우→ ⚠️ ConflictingBeanDefinitionException 에러 발생➕ 각 컴포넌트 이름을 service로 할 경우💻 실행화면⚠️ 오류 발생!!🤔 수동 빈 등록과 자동 빈 등록에서 빈 이름이 충돌되면 어떻게 될까

생성자 주입 수정자 주입(setter 주입)필드 주입일반 메서드 주입생성자를 통해서 의존관계를 주입받는다.생성자 호출 시점에 딱 한번만 호출, 이후 값 세팅을 막는다.➡️ ⭐불변이후에는 수정할 수 없다. (변경할 수 있는 방법 자체가 없다.❌)따라서 컨테이너 빌딩 이후

주입할 스프링 빈이 없어도 동작해야할 때가 있다.@Autowired의 required 옵션의 기본값이 true @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨➡️ 실행 결과 : 호출 되지 않는다. org.s

대부분의 경우 의존관계를 변경하지 않기 떄문에, 변경하지 못하는 생성자 주입이 최고👍setXxx 메서드를 public으로 열어두어야 한다. ➡️ 위험성이 있는 설계 방법😣 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. ✔️ 따라서

🥹들어가면서🥹

@Autowired는 타입으로 빈을 조회하게 된다. 상황 1.➡️ 따라서 구체 클래스가 아닌, 인터페이스로 조회하게 된다. ⚠️ 이때 인터페이스를 구현한 빈이 두개 이상인 경우를 생각해보자. 상황 2.💻 실행화면 ➡️ ⚠️ 오류 메시지@Autowired 는 타입 매칭

📒 애노테이션은 상속이 없고 조합만 제공한다.👤 나는 @Qualifier의 기능을 하는 애노테이션을 만들고자 한다.👉 @Qualifier기능을 가능하게 해주는 애노테이션 확인➕ @Qualifier기능을 가능하게 해주는 애노테이션 ➕ @Qualifier👉 지정 명

😢들어가면서😢 📌 조회한 빈이 모두 필요할 때 : List, Map 🤔 조회한 빈이 모두 필요한 상황? 클라이언트가 스프링 빈을 선택하는 상황 ⚠️ 경고가 뜨는데

🥹들어가면서🥹 📌 자동 수동의 올바른 실무 운영 기준

객체의 초기화와 종료작업이 필요한 경우가 있다.애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료시점에 연결을 모두 종료하는 작업 시 ex ) 데이터베이스 커넷션 풀이나, 네트워크 소캣서버가 뜰 때 → 미리 연결 서버 종료 → 외부 네트워크 연결 미

스프링 빈이 존재하는 범위를 말한다.기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.➡️ 빈 생성 , 의존관계 주

웹 환경에서만 동작한다.스프링이 해당 스코프의 종료시점까지 관리한다.따라서 종료 메서드가 호출된다.request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.session: HTTP