Spring

컨트롤러에서 리턴 값으로 문자를 반환하면, viewResolver가 화면을 찾아서 처리한다.resources:templates/ +{ViewName} + .html

✔ 스프링 웹 개발 기초 스프링 부트가 제공하는 기능들 > > ### ✅ 정적 컨텐츠 > ✅ MVC와 템플릿 엔진 HTML을 동적으로 바꾸는 것을 템플릿 엔진이라 한다. JSP나 PHP 등이 템플릿 엔진에 해당된다. Model View Controller (MVC) >

✔ 비즈니스 요구사항 정리 데이터 : 회원ID, 이름 기능 : 회원 등록, 조회 아직 데이터 저장소가 선정되지 않음 > - 컨트롤러 : 웹 MVC의 컨트롤러 역할 > - 서비스 : 핵심 비즈니스 로직 구현 예 ) 회원 중복 가입 안되는 로직 > - 리포지토리 : 데이

✔ 회원 레포지토리 테스트 케이스 작성 > #### 💡 개발한 기능을 실행해서 테스트 하는 기존 방법들 > - 개발한 기능을 실행해서 테스트 할 때 자바의 main 메서드를 통해서 실행하거나 > - 웹 애플리케이션의 컨트롤러를 통해 해당 기능을 실행함 > > 위의 방

✔ 회원 서비스 회원가입 메서드 > - 기본 회원가입 메서드 > - Optional 감싸기 제거 > - 메서드 추출 ( ctrl + alt + m )

같은 패키지에 SpringConfig Class를 생성해 직접 스프링 빈을 등록해주는 코드를 넣어준다.DI에는 필드 주입, setter 주입, 생성자 주입 이렇게 3가지 방법이 있다. 의존 관계가 실행 중에 동적으로 변하는 경우는 거의 없으므로 생성자 주입을 권장한다.

회원 웹 기능 - 홈 화면 추가

H2 데이터베이스 member 테이블 생성테이블에 데이터 insert기존의 interface를 두고 구현체를 바꾸어 낄 수 있으며, 다형성을 편리하게 구현할 수 있다.( 기존의 코드는 그대로 두고 변경해야 하는 부분만 바꿀 수 있다 )DataSource는 데이터베이스

순수 Jdbc와 동일한 환경설정스프링 JdbcTemplate과 MyBatis 같은 라이브러리는 JDBC API에서 본 반복 코드를 대부분 제거SQL은 직접 작성

JPA

모든 메서드의 호출 시간을 측정하고 싶다면?공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern)공통 관심 사항과 핵심 관심 사항을 분리해야 한다.회원 가입 시간, 회원 조회 시간을 측정하고 싶다면?MemberServic

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉 "객체"들의 모임각각 객체는 메시지를 주고받고, 데이터를 처리할 수 있음객체 지향 프로그래밍은 프로그램을 유연하고 변경 용이하게 만들기 때문에 대규모 소프트웨어

스프링 없는 순수한 자바로만 개발을 진행해보자회원회원을 가입하고 조회할 수 있다.회원은 일반과 VIP 두 가지 등급이 있다.회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)주문과 할인 정책회원은 상품을 주문할 수 있다.회원 등급에

고정 금액 할인이 아니라 정률 할인으로 변경하고자 한다.새로 나온 정책은 10%로 지정해두어서 할인을 해주는 것이다.정률 할인 정책 구현 객체정률 할인 정책 테스트테스트 코드 작성 결과 - 실패할 경우새로운 할인 정책을 애플리케이션에 적용하기할인 정책을 변경하려면 Or

관심사의 분리 애플리케이션을 하나의 공연이라고 생각해봅시다! 각각의 인터페이스는 배역(배우 역할)이다. 실제 배역을 맞는 배우를 선택하는 것을 누가 할까? 배우가 직접 역할에 맞는 배우를 정하는 것이 아니다. 이전에서 우리 코드는...🙄 구현체가 구현체를 호출

FixDiscountPolicy → RateDiscountPolicyAppConfig로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성하는 영역으로 관리되고 있다.FixDiscountPolicy → RateDiscountPolicy 로 변경하면 된다.AppCon

다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없다.새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야 하는 문제점이 발생한다.주문 서비스 클라이언트가 인터페이스인 DiscountPo

우리가 짠 코드를 SRP, DIP, OCP 세 가지 원칙 측면에서 살펴보자💡 한 클래스는 하나의 책임만 가져야 한다.클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있다.SRP 단일 책임 원칙을 따르면서 관심사를 분리해야 한다.

기존 프로그램은 클라리언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.구현 객체가 프로그램의 제어 흐름을 스스로 조종했다.개발자 입장에서는 자연스러운 흐름!AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당

@Configuration은 애플리케이션의 설정 정보를 담고 있다.애플리케이션의 설정을 구성한다는 뜻!각 메서드에 @Bean을 붙여준다.이는 스프링 컨테이너에 스프링 빈으로 등록한다.아래와 같은 결과가 나오는 것을 확인할 수 있어요~!@ApplicationContext

스프링 컨테이너가 생성되는 과정ApplicationContext를 스프링 컨테이너라 한다.ApplicationContext는 인터페이스!스프링 컨테이너는 XML 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. ( 요즘은 XML 기반 거의

내부 및 외부에서 생성한 Bean에 대해 출력하는 것을 확인할 수 있다.우리가 설정한 Bean 5개만 출력되는 것을 확인할 수 있다.모든 빈 출력하기실행하면 스프링에 등록된 모든 빈 정보를 출력할 수 있다.ac.getBeanDefinationNames() : 스프링에

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

스프링 컨테이너의 최상위 인터페이스스프링 빈을 관리하고 조회하는 역할 담당getBean() 제공지금까지 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능!BeanFactory의 기능을 모두 상속받아서 제공빈을 관리하고 검색하는 기능을 BeanFactory가

애노테이션 기반 자바 코드 설정 사용지금까지 했던 방식!AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘긴다. AppConfig.classXML 설정 사용최근에는 스프링 부트를 많이 사용하면서 XML 기반의

스프링은 어떻게 이런 다양한 설정 형식을 지원할까?추상화 개념, 빈 설정 메타 정보@Bean, <bean> 당 각각 하나씩 메타 정보가 생성된다.스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.역할과 구현을 개념적으로 나눈 것XML을 읽어서 Bean

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.대부분의 스프링 애플리케이션은 웹 애플리케이션!웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다.고객이 3번 요청하면 객체가 3번 생성되어야 하는 문제가 발생한다.결과를 보면 memberServi

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 여기서 스프링 빈이 싱글톤으로 관리되는 빈이다.스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.스프링 컨테이너는 싱글톤 컨테이

스프링 빈을 등록할 때 자바 코드의 @Bean이나 XML의 <bean>을 통해 설정 정보에 직접 등록할 스프링 빈을 나열했다.만약, 등록해야할 스프링 빈이 수십, 수백개가 된다면?스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공

의존관계 주입 방법은 크게 4가지가 있다.생성자 주입수정자 주입 (setter 주입)필드 주입일단 메서드 주입생성자를 통해서 의존 관계를 주입 받는 방법생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.불변, 필수 의존관계에 사용한다.🚨 생성자가 딱 1개만 있으면

조회 빈이 2개 이상 - 문제 는 타입(Type)으로 조회한다. 타입으로 조회하기 때문에 마치 다음 코드와 유사하게 동작한다. 스프링 빈 조회에서 학습했듯이 타입으로 조회하면 선택된 빈이 2개 이상일 때 문제가 발생한다. 하위 타입인 , 둘 다 스프링 빈으로 선언

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.스프링을 통해 이러한 초기화 작업과 종료 작업을 어떻게 진행할까?

스코프 : 빈이 존재할 수 있는 범위스프링 빈은 기본적으로 싱글톤 스코프로 생성된다.스프링 빈이 스프링 컨테이너이 시작과 함께 생성되어서 스프링 컨테이너가 종료될때까지 유지된다.싱글톤기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프프로토

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