다음 테스트 코드에서 @Transactional, @Rollback의 역할을 알아본다. testMember 테스트 메소드 내 memberRepository를 사용하기 위해서 @Transactional 어노테이션이 필요하다. 없으면 다음 에러가 뜬다. Transaction 메소드를 사용하기 위해 필요해 보인다. @Rollback 값은 기본적으로 true다. @Transactional을 통해 DB에 변경사항이 반영이 되지 않고 롤백 된다. 따라서 save를 통한 insert 쿼리를 확인할 수 없다. 이를 확인하기 위해 @Rollback 어노테이션 값을 false로 두어 공부할 때 확인한다. 롤백하지 않으면 위처럼 insert 쿼리를 확인할 수 있다.

Environment ApplicationContext는 EnvironmentCapable 인터페이스를 상속해 environment를 제공한다. EnvirionmentCapable 인터페이스 내용은 다음과 같다. Environment는 애플리케이션의 개발 환경, 테스트 환경, 운영 환경 등을 의미한다. 개발 중에는 H2 DB를 사용하다가 운영 중에는 MySQL을 사용해 환경을 바꿀 수 있다. 스프링의 환경은 Profile과 Property로 제공한다. Profile에 따라 환경이 바뀌고 그에 따라 Property Source가 바뀐다. Properties DB 접속 정보, 서버 포트 정보 등 다양한 정보를 코드 상에 직접 작성하면 배포마다 바꿔야하거나 패스워드 같은 민감한 정

Bean Lifecycle Callbacks Bean 생성 생명주기 콜백 @PostConstruce 애노테이션이 적용된 메소드 호출 Bean이 InitializingBean 인터페이스 구현시 afterPropertiesSet 호출 @Bean 애노테이션이 initMethod에 설정한 메소드 호출 Bean 소멸 생명주기 콜백 @PreDestroy 애노테이션이 적용된 메소드 호출 Bean이 DisposableBean 인터페이스 구현시 destroy 호출 @Bean 애노테이션의 destroyMethod에 설정한 메소드 호출 다음과 같은 코드로 확인할 수 있다. 실행 결과 콜백 메소드 순서는 다음과 같다. 빈을 정의할 때 @Bean 어노테이션의 initMethod 속성을 이용해 초기화 메소드를 지정할 수 있다. 실행 결과는 다음과 같고 init 메소드가 나중에 실행된다.

스프링 공식문서에서 총 6개의 빈 스코프를 볼 수 있다. 기본적으로 싱글톤 스코프를 가진다. 다음과 같이 같은 빈에 대해서 equal 비교를 했을 때 true 결과를 볼 수 있다. 스코프를 임의로 변경할 수 있는데 @Scope 어노테이션을 이용해 바꿀 수 있다. 아래와 같이 빈 클래스 파일에서 PROTOTYPE 스코프로 바꿀 수 있다. 스코프를 변경 후 equal 비교를 했을 때 다른 객체임을 확인할 수 있다. ![](https://velog.velcdn.com/images/leehanju408/po

컴포넌트 스캔으로 빈 등록 컴포넌트 스캔은 스프링이 직접 클래스를 검색해서 빈으로 등록해주는 기능이다. 설정 클래스에 빈으로 직접 등록하지 않아도 원하는 클래스를 빈으로 등록할 수 있다. Stereotype 애노테이션을 이용하면 스캔대상을 지정한다. 스프링에서는 @Component, @Controller, @Service, @Configuration 등을 사용한다. 예제 기존 AppConfiguration 코드에서 VoucherService, OrderService를 빈으로 등록하는 코드를 제거한다. 다음과 같이 AppConfiguration 코드에 @ComponentScan 어노테이션을 붙여 컴포넌트 스캔으로 빈을 등록한다. AppConfiguration에서 등록한 빈들은

A -> B 를 참조하고, B -> A를 참조할 경우 순환 의존관계를 형성한다. 이는 BeanCurrentlyInCreationException을 발생한다. 다음은 순환 의존관계를 가지는 코드다. 실행하면 다음과 같이 오류를 볼 수 있다. 애플리케이션을 실행하면 이제 스프링 컨테이너(IoC)는 A 빈을 생성하기위해 B를 주입해줘야하기 때문에 B를 찾는다. 근데 B를 생성하려 하니 A를 주입하기위해 A를 찾게되면서 무한 반복이 생긴다.

IoC는 다양한 방법으로 만들 수 있다. 전략 패턴, 서비스 로케이터 패턴, 팩토리 패턴, 의존관계 주입 패턴들이 있다. 지금까지 쓴 생성자를 통해서 객체를 주입받는 패턴을 생성자 주입 패턴(DI)이라고 부른다. 스프링은 생성자 주입을 권장한다. 애플리케이션 구성 요소를 불변 객체로 구현하고 필요한 종속성이 null이 되지 않도록 보장한다. 생성자의 파라미터는 항상 초기화된 상태로 클라이언트 코드로 반환된다. [https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-setter-injection](https://docs.spring.io/spring-framework/docs/current/refe

IoC 컨테이너는 객체에 대한 생성과 조합이 가능하게하는 프레임워크다. 스프링에서는 IoC 컨테이너를 ApplicationContext인터페이스로 제공한다. ApplicationContext는 BeanFactory를 상속한다. 객체에 대한 생성, 조합, 의존관계 설정 등을 제어하는 IoC 기본기능은 BeanFactory에서 담당한다. Bean은 IoC 컨테이너에 의해 관리되는 객체다. ![](https://velog.velcdn.com/images/leehanju408/post/8421d6be-a931-43e

IoC 제어의 역전이란 이런 제어의 흐름의 역전이 되는것을 말한다 . IoC 상황에서는 객체가 자신이 사용할 개체를 스스로 선택하지 않고 스스로 생성도 하지 않는다 . 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어하지만 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 프레임워크가 흐름을 주도하면서 개발자가 만든 애플리케이션 코드를 사용하는 것이다. 즉 , 애플리케이션 코드가 프레임워크가 짜놓은 틀에서 수동적으로 동작한다. 이를 Hollywood Principle이라고도 한다. 예제 현재 실행 클래스에서 Order 엔터티가 사용할 클래스 FixedAmountVoucher를 결정하고 해당 클래스의 객체를 직접 생성한다. 또한 Order 객체도 여기서 직접 생성한다. 즉 모든 종류의 작업을 사용하는 쪽에서 제어를 하는 구조다. 이를 간단하게 애플리케이션의 주요 객체에 대해서 생성과 관계설정을 하는 OrderCont

의존성 어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이의 의존성이 존재하게 된다. 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다. 컴파일타임 의존성: 코드를 작성하는 시점에서 발생하는 의존성. 클래스 사이의 의존성. 런타임 의존성: 애플리케이션이 실행되는 시점의 의존성. 객체 사이의 의존성. 결합도 결합도란 "하나의 객체가 변경이 일어날 때에 관계를 맺고 있는 다른 객체에게 변화를 요구하는 정도"라고 볼 수 있다. 어떤 두 요소 사이에 존재하는 의존성이 바람직할 때 두 요소가 느슨한 결합도 또는 약한 결합도 를 가진다고 말한다. 반대로 두 요소의 의존성이 바람직하지 못할 때 단단한 결함도 또는 강한 결합도를 가진다고 말한다. 예제 다음 Order 클래스는 dicsountAmount 필드를 통해 totalAmount 메소드에서 직접 할인 로직을 정한다. 이를 변경해 Voucher 클래스를 통해 할인

기존 매퍼 클래스 entity → dto 변환을 생성자를 통해 직접 해줘야한다. MapStruct 인터페이스 다음과 같이 인터페이스에 메소드 정의만 하면 됨 인터페이스 위에 @Mapper 어노테이션 사용 MapStruct를 실제 이용 MapStruct 인터페이스에서 정의한 static 변수를 이용해 메소드에 접근한다. 사용 방법은 기존 매퍼 클래스와 크게 다르지 않다. 인터페이스의 구현체는 어디서? MapStruct 인터페이스를 정의하고 프로그램을 실행하면 다음과 같이 generated 폴더가 생긴다. 다음과 같이 인터페이스명Impl 클래스를 확인해보면 자동으로 인터페이스에서 정의한 메소드의 인자와 반환 값에 맞는 매핑 로직을 만

스프링의 코어가 DI, AOP 컨테이너다. DI란? DI는 인터페이스를 이용해 컴포넌트화를 실현하는 것이다. DI를 우리말로 옮기면 의존 관계의 주입이다. 오브젝트 사이의 의존 관계를 만드는 것이다. 어떤 오브젝트의 프로퍼티에 그 오브젝트가 이용할 오브젝트를 설정한다는 의미다. 이를 어떤 오브젝트가 의존(이용)할 오브젝트를 주입 혹은 인젝션(프로퍼티에 설정) 한다는 것이다. DI를 구현하는 컨테이너는 클래스의 인스턴스화 등의 생명 주기 관리 기능이 있는 경우가 많다. 다음은 인터페이스를 이용하지 않는 단순한 웹 애플리케이션이다. ProductSampleRun이 ProductService를 new 하고 ProductService가 ProductDao를 new한 다음 각각의 인스턴스를

Spring MVC Spring MVC 란 Spring 프레임워크에서 제공하는 웹 모듈이다. MVC 는 Model-View-Controller 의 약자로, 기본 시스템 모듈을 MVC 로 나누어 구현되어있다. Model 은 '데이터' 디자인을 담당한다. ex. 상품 목록, 주문 내역 등 View 는 '실제로 렌더링되어 보이는 페이지' 를 담당한다. ex. thymeleaf 파일들이 여기에 해당된다. Controller 는 사용자의 요청을 받고, 응답을 주는 로직을 담당한다. ex. GET 등의 uri 매핑이 여기에 해당된다. Spring MVC 모듈을 사용하여, 백엔드 프로그래밍의 기본 프레임워크를 잡는다. Web 서버에 특화되어 만들어진 모듈이라, 개발자가 해야할 영역을 더 적게 만들어준다. 즉 기존에 Spring 보다 더 깔끔하고 간편하게 개발

IOC란 IoC란 Inversion of Control의 약자로 해석하자면 제어의 역전이다. 제어의 역전은 제어권이 뒤 바뀌었다는 뜻이다. 이말은 기존의 제어방식을 뒤집었다는 말이 된다. 그렇다면 기존의 방식은 어떠했는가 살펴보자. 자바가 등장하고 자바 기반의 어플리케이션이 개발되던 초기에는 자바 객체를 생성하고 객체간의 의존관계를 연결하는 등의 제어권을 개발자가 직접 가지고 있었다고 한다. 그러나 서블릿, EJB가 등장하면서 개발자가 독점적으로 가지고 있던 제어권이 서블릿과 EJB를 관리하는 외부의 컨테이너로 넘어갔다. 객체의 생성부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 IoC, 제어의 역전이라 하는것이다. IOC 컨테이너 모든 작업을 사용하는 쪽에서 제어하게 되면서 IoC컨테이너에서 제어하게 된다. 기본적으로 컨테이너는 객체를 생성하고 객체간의 의존성을 이어주는 역할을 한다. BeanFactory BeanFa

의존성 주입은 프로그램 디자인이 결합도를 느슨하게 한다. 의존성 주입은 의존관계 역전 원칙과 단일 책임 원칙을 따르도록 한다. 클라이언트의 객체 생성에 대한 의존성을 클라이언트의 행위로부터 분리하는 것이다. 의존성 주입은 다음과 같은 문제를 해결한다. 어떻게 애플리케이션이나 클래스가 객체의 생성 방식과 독립적일 수 있는가? 어떻게 객체의 생성 방식을 분리된 구성 파일에서 지정할 수 있는가? 어떻게 애플리케이션이 다른 구성을 지원할 수 있는가? 객체를 필요로하는 클래스 내에서 직접 객체를 생성하는 것은 클래스를 특정 객체에 커밋하는 것이다. 이후에 클래스로부터 독립적으로(클래스의 수정 없이) 인스턴스의 생성을 변경하는 것이 불가능하기 때문에 유연하지 못하다. 이는 다른 객체를 필요로하는 경우 클래스를 재사용할 수 없게한다. 또한 실제 객체를 모의 객체로 대체할 수 없기 때문에 클래스를 테스트하기 힘들게한다. DI 등장 예시 ![](https://ve

스프링은 다른 프레임워크에 비해 다음과 같은 특징을 가진다. 경량 컨테이너로서 자바 객체를 직접 관리한다. 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다. 스프링은 Plain Old Java Object 방식의 프레임워크이다. 일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다. 스프링은 제어 반전(IoC : Inversion of Control)을 지원한다. 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다. 스프링은 의존성 주입(DI : Dependency Injection)을 지원한다. 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다. 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented

스프링 웹 계층 스프링 프로젝트를 할 때 다음과 같이 계층을 나눌 수 있다. 스프링 계층은 크게 3개로 나눌 수 있다 Presentation Layer Business Layer Data Access Layer 프레젠테이션 계층 브라우저상의 웹 클라이언트의 요청 및 응답을 처리한다. Service Layer, Data Access Layer에서 발생하는 Exception 처리 @Controller 클래스가 이 계층에 속한다. Controller 컨트롤러는 사용자의 요청을 처리한 후 지정된 뷰에 모델 객체를 넘겨주는 역할을 한다. 사용자의 요청이 진입하는 지점이며 요청에 따라 어떤 처리를 할 지 결정을 해 Service에 넘겨준다. 서비스 계층

스프링 프레임워크에서는 다음과 같은 디자인 패턴을 사용한다. 싱글톤 패턴 팩토리 메소드 패턴 프록시 패턴 템플릿 패턴 싱글톤 패턴 싱글톤 패턴은 객체에 대해 하나의 인스턴스만 존재하는 것을 보장하는 기법이다. 공유 자원을 관리하거나 로깅과 같은 횡단 서비스를 제공할 때 유용하다. 싱글톤 빈(bean) Spring IOC 컨테이너 당 하나의 객체로 싱글톤을 제한한다. 즉 Spring은 애플리케이션 컨텍스트 당 각 타입에 대해 하나의 빈만 생성한다. 애플리케이션은 두 개 이상의 스프링 컨테이너를 가질 수 있기 때문에 일반적인 싱글톤과는 다르다. 여러 컨테이너가 있는 경우 여러 객체가 애플리케이션에 존재할 수 있다. 팩토리 메소드 패턴 팩토리 메