목차 요청 매핑 요청 매핑 - api 예시 HTTP 요청 - 기본, 헤더 조회 HTTP 요청 파라미터 - 쿼리 파라미터, HTML Form HTTP 요청 파라미터 - @ModelAttribute HTTP 요청 메시지 - 단순 텍스트 HTTP 요청 메시지 - JSON HTTP 응답 - 정적 리소스, 뷰 템플릿 HTTP 응답 - HTTP API, 메시지 바디에 직접 입력 1. 요청 매핑 매핑 정보 @Controller @Controller는 반환 값이 String이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다. @RestController는 반환 값으로 뷰를 찾는게 아니라, HTTP메시지 바디에 바로 입력한다. 따라서 실행결과로 ok 메세지를 받을 수 있다. @ResponseBody와 관련이 있는데, 뒤에서 더 자세히 설명한다. @RequestMapping("/

목차 스프링 MVC 전체 구조 핸들러 매핑과 핸들러 어댑터 스프링 MVC - 시작하기 스프링 MVC - 컨트롤러 통합 스프링 MVC - 실용적인 방식 1. 스프링 MVC 전체 구조 이전 시간에 직접 만들었던 MVC 프레임워크와 지금 우리가 사용하고 있는 스프링 MVC를 비교해보자. 직접 만든 MVC 프레임워크 구조 Spring MVC 구조 직접 만들었던 MVC 프레임워크와 스프링 MVC 프레임워크와 이름만 다를 뿐, 동작 방식이 같다. 우리가 흔히 알고있는 어노테이션을 이

목차 Hello 서블릿 HttpServletRequest - 개요 HTTP 요청 데이터 - 개요 HTTP 요청 데이터 - GET 쿼리 파라미터 HTTP 요청 데이터 - POST HTML Form HTTP 요청 데이터 - API 메시지 바디 - 단순 텍스트 HTTP 요청 데이터 - API 메시지 바디 - JSON HttpServletResponse - 기본 사용법 HTTP 응답 데이터 - 단순 텍스트, HTML HTTP 응답 데이터 - API JSON 정리 1. Hello 서블릿 서블릿에 대해 알고 싶다면 --> https://velog.io/@yoon_bly/Servlet%EA%B3%BC-JSP 서블릿은 톰캣 같은 웹 어플리케이션 서버를 직접 설치하고, 서블릿 코드를 클래스 파일로 빌드해서 올린 후, 톰캣 서버를 실행해야 한다. 하지만 방법이 복잡하기 때문에 우리는 좀더 발전된 기술 "스프링 부트

목차 빈 스코프란? 프로토타입 스코프 웹 스코프 request 스코프 예제 만들기 스코프와 Provider 스코프와 프록시 1. 빈 스코프란? 지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 빈 스코프는 말 그대로 빈이 존재할 수 있는 범위를 뜻한다. 스프링은 다음과 같은 다양한 스코프를 지원한다. 스프링은 다양한 스코프를 지원한다. 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다. 웹 관련 스코프 request : 웹 요청이 들어오고 나갈 때 까지 유지되는 스코프 sess

목차 빈 생명주기 콜백 시작 인터페이스 InitializingBean, DisposableBean 빈 등록 초기화, 소멸 메서드 지정 어노테이션 @PostConstruct, @PreDestroy 1. 빈 생명주기 콜백 시작 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해보자. 실제로 네트워크에 연결하는 것은 아니고, 단순히 문자만 출력하도록 했다. 이 NetworkClient 는 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 하고, 애플리케이션이 종료되면 disConnect() 를 호출해서 연결을 끊어야 한다. 예제 코드 스프링 환경설정과 실행 테스트를 실행해보면 다음과

목차 다양한 의존관계 주입 방법 생성자 주입을 선택해라! 롬복과 최신 트랜드 조회 빈이 2개 이상 - 문제 @Autowired 필드 명, @Qualifier, @Primary 애노테이션 직접 만들기 조회한 빈이 모두 필요할 때, List, Map 자동, 수동의 올바른 실무 운영 기준 1. 다양한 의존관계 주입 방법 의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 1-1. 생성자 주입 생성자를 통해 의존관계를 주입하는 방법이다. 생성자 주입 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다. 불편, 필수 의존관계에 사용 > 중요! 단일 생성자일 경우(생성자가 1개) @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다. 1-2. 수정자 주입(setter 주입)

목차 컴포넌트 스캔과 의존관계 자동 주입 시작하기 탐색 위치와 기본 스캔 대상 필터 중복 등록과 충돌 1. 컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다.(순수 자바코드로 스프링 빈 생성) 예제에서는 몇개가 안되었지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 역시 개발자는 반복을 싫어한다.(무엇보다 귀찮다 ㅠㅠ) 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 또 의존관계도 자동으로 주입하는 @Autowired 라는 기능도 제공한다. 먼저 기존 AppConfig.java는 과거 코드와 테스트를 유지하기 위해 남겨두고, 새로운 AutoAppC

목차 웹 애플리케이션과 싱글톤 싱글톤 패턴 싱글톤 컨테이너 싱글톤 방식의 주의점 @Configuration과 싱글톤 @Configuration과 바이트코드 조작의 마법 1. 웹 애플리케이션과 싱글톤 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있다. 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 1-1. 스프링 없는 순수한 DI 컨테이너 테스트 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. 고객 트래픽이 초당 100이 나오면 초당

목록 스프링 컨테이너 생성 컨테이너에 등록된 모든 빈 조회 스프링 빈 조회 - 기본 스프링 빈 조회 - 동일한 타입이 둘 이상 스프링 빈 조회 - 상속 관계 BeanFactory와 ApplicationContext 다양한 설정 형식 지원 - 자바 코드, XML 스프링 빈 설정 메타 정보 - BeanDefinition 1. 스프링 컨테이너 생성 스프링 컨테이너가 생성되는 과정을 알아보자. ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스로 이루어져 있다.(다형성이 적용) 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( Applicat

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

5. 새로운 구조와 할인 정책 적용 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자. FixDiscountPolicy -> RateDiscountPolicy 우리는 좋은 객체 지향 설계를 위해 DIP와 OCP원칙을 지키기 위해 구성 영역(AppConfig)를 만들었다. AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 그림 - 사용, 구성의 분리 그림 - 할인 정책의 변경 **할인 정책 변경 구성

목차 새로운 할인 정책 개발 새로운 할인 정책 적용과 문제점 관심사의 분리 AppConfig 리팩터링 새로운 구조와 할인 정책 적용 전체 흐름 정리 좋은 객체 지향 설계의 5가지 원칙의 적용 IoC, DI, 그리고 컨테이너 스프링으로 전환하기 1. 새로운 할인 정책 개발 새로운 할인 정책을 확장해보자. 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요! 우리는 이전까지 1000을 할인 하는 정액 할인 정책을 생각하여 개발해왔지만, 기획자가 할인 정책을 정액 할인 정책이 아닌 정률

1. 비즈니스 요구사항과 설계 회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 요구사항 문제점 및 해결방법 문제점 요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때 까지 개발을 무기한 기다릴 수 도 없다. 우리는 앞에서 배운 객체 지향

목차 스프링이란? 좋은 객체 지향 프로그래밍이란? 좋은 객체 지향 설계의 다섯가지 원칙(SOLID) 객체 지향 설계와 스프링 1. 스프링이란? 1-1. 스프링 JAVA의 웹 프레임워크로 JAVA 언어를 기반으로 사용 JAVA로 다양한 어플리케이션을 만들기 위한 프로그래밍 틀 스프링의 특징 IoC 컨테이너(IOC를 구현하는 프레임워크)로서 객체를 직접 관리. 객체 생성, 소멸 같은 생명주기 관리, 의존성 관리 IOC(Inversion of Control) 제어권의 역전. 제어권이 스프링 프레임워크에 있음. 개발자가 제어권을 가지지 않음. 객체가 내부적으로 조작할 객체를 직접 생성하는 것이 아니라 외부로부터 주입받는 것. 이때 객체를 외부로부터 주입해주는 작업을 DI라고 함. DI(Dependency Injection) 의존성 주입. 계층이나 서비스 간에 의존성이 존재할 경우 스프링 프레임워크가 서로 연결 AOP

AOP AOP란, Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불리는 스프링 3대 요소중 하나이다. 그리고 흩어진 Aspect를 모듈화할 수 있는 프로그래밍 기법입니다. 요번 게시글에서는 AOP를 간단한 예제를 통해서 알아보자. 자세한 내용은 나중에 다시 다루는 걸로 한다. 가장 유명한 예시로는 실행시간 출력 예제이다. AOP 예제 모든 메서드의 호출시간을 출력해야 할 때 각각의 메서드에 시간 측정 로직을 작성해야한다. MemberService 회원 조회 시간 측정 추가 지금은 간단한 예제이므로 메서드가 몇개 없지만, 실제 실무에서는 수많은 메서드가 있을 것이다. 많은 메서드에 시간 측정 로직을 작성하려면 사실상 노가다에 가깝다.

스프링 DB 접근 기술 > 순수 Jdbc 스프링 통합 테스트 스프링 JdbcTemplate JPA 스프링 데이터 JPA 순수 Jdbc Jdbc란 Java DataBase Conectivity의 약자로 자바 프로그램이 DB와 연결되어 데이터를 주고 받을 수 있게 해주는 프로그래밍 인터페이스이다. 이렇게 JDBC API로 직접 코딩하는 것은 20년 전 이야기이다. 따라서 고대 개발자들이 이렇게 고생하고 살았구나 생각하고, 정신건강을 위해 참고만 하고 넘어가자. 현재는 JPA나 MyBatis등으로 DB에 접근한다. 환경설정 build.gradle 파일에 jdbc, h2 데이터베이스 관련 라이브러리 추가 스프링 부트 데이터베이스 연결 설정 추가 resources/application.properties Jdbc 리퍼지토리 구현 스프링 설정 변경 DataSource는 데이터베이스 커넥션을 획득할

회원 관리 예제 - 웹 MVC개발 >- 회원 웹 기능 - 홈 화면 추가 회원 웹 기능 - 등록 회원 웹 기능 - 조회 회원 웹 기능 - 홈 화면 추가 홈 컨트롤러 추가 src/main/java 하위 폴더에 HomeController 파일을 생성 > @GetMapping("/") localhost:8080/ 요청시 나타내는 홈화면을 나타냄 회원 관리용 홈 src/main/resources/templates에 home.html을 생성 > 참고: 컨트롤러가 정적 파일보다 우선순위가 높다. 스프링 컨테이너에 관련 컨트롤러 빈이 없다면 정적 html파일(index.html)이 우선이지만, 컨트롤러 빈이 있다면 해당 컨트롤러에서 Mapping한 파일이 우선시 된다. 회원 웹 기능 - 회원 가입 회원 가입 폼 컨트롤러 form 객체는 태그를 이용하여 각종 입력양식을 통해 입력받아 서버로

스프링 빈(bean)이란 > 스프링(Spring) 컨테이너가 관리하는 자바 객체를 빈(Bean)이라 한다. 스프링의 특징에는 제어의 역전(IoC)이 있다. 제어의 역전(IoC)이란, 간단히 말해서 객체의 생성 및 제어권을 사용자가 아닌 스프링에게 맡기는 것이다. 지금까지는 사용자가 new연산을 통해 객체를 생성하고 메소드를 호출했다. IoC가 적용된 경우에는 이러한 객체의 생성과 사용자의 제어권을 스프링에게 넘긴다. 사용자는 직접 new를 이용해 생성한 객체를 사용하지 않고, 스프링에 의하여 관리당하는 자바 객체를 사용한다. 이 객체를 '빈(bean)'이라 한다. 스프링 빈을 등록하는 방법은 2가지가 있다. 컴포넌트 스캔과 자동 의존관계 설정 자바 코드로 직접 스프링 빈 등록하기 컴포넌트 스캔 컴포넌트 스캔이란 > 컴포넌트 스캔이란 스프링이 스프링 빈(Bean)으로 등록될 준비가 된 클래스들을 스캔하여 빈(Bean)으로 등록해주는

비즈니스 요구사항 정리 데이터: 회원ID, 이름 기능: 회원 등록, 조회 아직 데이터 저장소가 선정되지 않음(가상의 시나리오) (RDBMS를 쓸지, NoSQL을 쓸지) 일반적인 웹 애플리케이션 계층 구조 컨트롤러: 웹 MVC의 컨트롤러 역할 서비스: 핵심 비즈니스 로직 구현 리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리 도메인: 비즈니스 도메인 객체, ex) 회원, 주문, 쿠폰 등등 주로 데이터베이스에 저장하고 관리됨 클래스 의존관계 아직 데이터 저장소가 선정되

정적 컨텐츠 기본적으로 스프링에서는 정적 컨텐츠를 /static 폴더에서 찾는다. 따라서 스프링은 localhost:8080뒤에 /static 폴더 안의 원하는 정적 컨텐츠(html)의 이름을 붙히면 해당 정적 파일이 자동으로 나온다. 웹 브라우저에서 localhost:8080/hello-static.html을 보낸다 url을 보내면, 내장 톰켓 서버에서 요청을 받고, 스프링으로 넘겨준다. 스프링은 제일 먼저 Controller에서 hello-static에 관련된 것들을 찾는다. Mapping된 Controller가 없으면 resources:static/hello-static.html(정적 컨텐츠)을 찾는다. hello-static.html을 웹브라우저로 반환