[SPRING] STUDY

김영한님의 스프링 완전정복 로드맵스프링 부트와 JPA 실무 완전 정복 로드맵

https://start.spring.io/Project: Gradle Project -> 요즘에는 Gradle, Gradle-Groovy Projectgroup -> 보통 기업명, 단체artifactld -> project-nameDependencies ->

Spring은 정적 컨텐츠를 제공한다.static에서 정적 파일을 던져준다. (프로그래밍 불가)localhost:8080/hello.html -> controller에서 매핑이 된 url이 있는지 확인 -> 없으면 static에서 해당 정적 파일을 찾아서 반환Model

컨트롤러: 웹 MVC의 컨트롤러 역할서비스: 핵심 비즈니스 로직 구현리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리도메인: 비즈니스 도메인 객체, 예) 회원, 주문, 쿠폰 등등 주로 데이터베이스에 저장하고 관리됨아직 데이터 저장소가 선정되지 않아서

앞서 말했던 DI에 연장선이다.컴포넌트(Component)란 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈을 뜻한다.그림에서 확인 할 수 있듯이 컴포넌트 기반 프로그래밍을 하면 마치 레고 블록처럼 이미 만들어진 컴포넌들을 조합하여 화면을 구성할 수 있다.웹 컴포

home.html이라는 템플릿 파일을 보여준다.가입과 목록 조회 버튼이 있다.템플릿 파일에 form에서 name이라는 value에 값을 넣고 post요청하면 spring에서 setName으로 매개변수에 memberForm.name을 세팅해준다.from에 세팅된 name

공부용으로 적합한 H2를 사용하겠다.웹에서 실행되기 때문에 매우 가볍다.위처럼 테이블을 등록하고위처럼 데이터를 넣어보고 조회하면 아래처럼 잘 저장된 것을 볼 수 있다.20년 전 쯤 사용하던 JDBC 기술을 직접 사용해보자jdbc와 h2를 끌고온다.local H2 서버에

애플리케이션의 여러 컴포넌트 혹은 모듈간의 상호작용과 조정을 검증하는데 중점을 둔 소프트웨어 테스팅 유형이다.유닛 테스트에서 테스트된 유닛들이 결합되었을 때 올바르게 작동되는지를 확인한다.데이터 통신, 데이터 공유, 컴포넌트간 전반적 제어 흐름에 관련된 문제를 식별하는

JPA는 기존의 반복 코드는 물론이고, 기본적인 SQL도 JPA가 직접 만들어서 실행해준다.JPA를 사용하면, SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환을 할 수 있다. JPA를 사용하면 개발 생산성을 크게 높일 수 있다위 설정으로 JPA가 던

이 JPA를 인터페이스만으로 간단하게 해결하는 방법이 있다.아래를 보자이렇게 Interface로 JpaRepository와 MemberRepository만 상속 받고 key가 아닌 Name으로 조회했던 findByName메서드만 override하면 끝이다.이로써 지금까

AOP: Aspect Oriented Programming공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 분리회원가입, 회원 조회등 핵심 관심사항과 시간을 측정하는 공통 관심 사항을 분리한다. 시간을 측정하는 로직

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지 를 주고받고, 데이터를 처리할 수 있다. (협력)객체 지향 프로그래밍은 프로그램을 유연하고

회원회원을 가입하고 조회할 수 있다.회원은 일반과 VIP 두 가지 등급이 있다.회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)주문과 할인 정책회원은 상품을 주문할 수 있다.회원 등급에 따라 할인 정책을 적용할 수 있다.할인 정책은

비즈니스로 갑자기 고정값 할인해서 고정률 할인으로 바뀌어야 하는 상황이 왔다.하지만 객체 지향적 설계를 해놓았기 때문에 걱정이 없다.위처럼 할인이라는 역할(인터페이스)의 새로운 구현체인 RateDiscountPolicy를 만들었다.위와 같은 테스트도 통과했다.asser

지금까지 순수한 자바 코드만으로 DI를 적용했다. 이제 스프링을 사용해보자. 지금은 코드만 작성하고 설명은 마지막에 하겠다.AppConfig 스프링 기반으로 변경AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여준다.각 메서드에 @Bean 을

위와 같이 스프링 컨테이너를 생성한다.스프링 컨테이너는 BeanFactory, ApplicationContext로 크게 나눠지는데 여기서는 ApllicationContext가 스프링 컨테이너라고 생각하면 된다.ApplicationContext는 인터페이스이고 그 구현체

지금까지의 코드를 보면 100번의 요청이 들어오면 100다 instance를 생성해주었다.메모리 낭비가 매우 심해보인다.그래서 싱글톤을 적용한다.아래를 보자위와 같은 테스트를 하게 되면 당연히 통과한다.두 memberService는 다른 인스턴스일테니까issameAs

위처럼 컴포넌트로 등록해놓으면 스프링이 컴포넌트 스캔을 진행해서 스프링 빈 저장소에 넣어준다. @ComponentScan이라는 어노테이션이 붙은 설정파일의 패키지부터 그 하위패키지 전부를 스캔하게 되는데 사실 @SpringBootAplication을 통해 Comp

스프링에서는 다양한 의존관계 주입 방법들이 존재한다.의존관계 주입은 크게 4가지 방법이 있다.생성자 주입수정자 주입(setter 주입) 필드 주입일반 메서드 주입생성자 주입은 불변, 필수라는 특징을 갖고 있다.생성자이기 때문에 스프링 빈을 등록하는 단계에서 의존관계 주

다음 코드를 조금 간단하게 리팩토링 해보자생성자가 딱 1개만 있으면 @Autowired 를 생략할 수 있다.더 줄여보기 전에 lombok이라는 것을 알아보자.lombok 플러그인을 다운 받고 lombok 라이브러리를 땡겨온다.그리고 세팅에서 AnnotaionProces

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가

지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지된다 고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.스프링은 다음과 같

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

html 폼으로 post 요청을 했는데 웹 애플리케이션 서버(WAS)를 내가 직접 구현해 한다면 ?서버 TCP/OP 연결 대기, 소켓 연결HTTP 요청 메시지를 파싱해서 읽기POST 방식, /save URL 인지Content-Type 확인HTTP 메시지 바디 내용 파싱

주로 다음 3가지 방법을 사용한다. GET - 쿼리 파라미터/url?username=hello&age=20메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달 예) 검색, 필터, 페이징등에서 많이 사용하는 방식POST - HTML Formcontent-t

Servlet으로 간단한 회원 웹 애플리케이션을 만들어보자먼저 위처럼 간단한 도메인 로직을 작성한디.멤버 엔티티와 레포지토리를 생성한다.레포지토리 안에는 객체답게 그 객체를 다루는 메서드들이 있다.위처럼 폼을 생성한다.response 바디에 html를 직접 생성한다.a

이번엔 템플릿 엔진인 JSP를 사용해보자JSP는 자바 코드를 그대로 사용할 수 있고 자바가 중심이 아니라 HTML 중심으로 사용한다.위처럼 jsp로 html안에 자바코드를 작성한 폼을 만든다.위 코드에서는 회원가입이 성공하면 저장한 member의 정보를 보여준다위에서는

분배되지 않은 역할비즈니스 로직을 수정해야하는데 UI를 건드려야하고 UI를 건드릴 때도 비즈니스 로직이 함께 있는 파일을 수정해야한다.이게 수백 수천줄이라면 유지보수의 지옥이라고 할 수 있다.변경의 라이프 사이클사실 이게 정말 중요한데, 진짜 문제는 둘 사이에 변경의

이전에 MVC를 적용해봤지만 그 한계를 살펴보자.포워드 중복View로 이동하는 코드가 항상 중복 호출되어야 한다. 물론 이 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상직접 호출해야 한다. java RequestDispatcher dispatcher = req

저번에 FrontController로 직접 만들었던 MVC 프레임워크와 Spring MVC 구조를 비교해보자직접 만든 프레임워크 스프링 MVC 비교 FrontController -> DispatcherServlethandlerMappingMap -> HandlerMap

앞으로 로그를 사용할 것이기 때문에, 이번시간에는 로그에 대해서 간단히 알아보자.운영 시스템에서는 System.out.println() 같은 시스템 콘솔을 사용해서 필요한 정보를 출력하지 않고, 별도의 로 깅 라이브러리를 사용해서 로그를 출력한다.참고로 로그 관련 라이

위처럼 헤더별, 요청별, 파라미터별 등으로 매핑할 수 있다.매핑 방법을 이해했으니, 이제부터 HTTP 요청이 보내는 데이터들을 스프링 MVC로 어떻게 조회하는지 알아보자.위처럼 요청 헤더의 관한 내용들을 다 받을 수 있다.keyA를 꺼내면 배열이 나옴 {value1,

배운 것들을 활용하여 간단한 웹 페이지를 만들어보자상품을 관리할 수 있는 서비스를 만들어보자.디자이너: 요구사항에 맞도록 디자인하고, 디자인 결과물을 웹 퍼블리셔에게 넘겨준다.웹 퍼블리셔: 다자이너에서 받은 디자인을 기반으로 HTML, CSS를 만들어 개발자에게 제공한

기획자가 화면에 보이는 문구가 마음에 들지 않는다고, 상품명이라는 단어를 모두 상품이름으로 고쳐달라고 하면 어떻게 해야할까?여러 화면에 보이는 상품명, 가격, 수량 등, label 에 있는 단어를 변경하려면 다음 화면들을 다 찾아가면서 모두 변경 해야 한다. 지금처럼

지금까지 만든 웹 애플리케이션은 폼 입력시 숫자를 문자로 작성하거나해서 검증 오류가 발생하면 오류 화면으로 바로 이동한다. 이렇게 되면 사용자는 처음부터 해당 폼으로 다시 이동해서 입력을 해야 한다. 아마도 이런 서비스라면 사용 자는 금방 떠나버릴 것이다. 웹 서비스는

검증 기능을 지금처럼 매번 코드로 작성하는 것은 상당히 번거롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다. 다음 코드를 보자.Bean Validation 이란?먼저 Bean Validati

홈 화면 - 로그인 전 회원 가입로그인홈 화면 - 로그인 후본인 이름(누구님 환영합니다.) 상품 관리로그 아웃보안 요구사항로그인 사용자만 상품에 접근하고, 관리할 수 있음로그인 하지 않은 사용자가 상품 관리에 접근하면 로그인 화면으로 이동회원 가입, 상품 관리도메인이

요구사항을 보면 로그인 한 사용자만 상품 관리 페이지에 들어갈 수 있어야 한다.앞에서 로그인을 하지 않은 사용자에게는 상품 관리 버튼이 보이지 않기 때문에 문제가 없어 보인다. 그런데 문제는 로 그인 하지 않은 사용자도 다음 URL을 직접 호출하면 상품 관리 화면에 들

스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다.서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다. 둘다 웹과 관련 된 공통 관심 사항을 처리하지만, 적용되는 순서와

Exception(예외) 자바 직접 실행 자바의 메인 메서드를 직접 실행하는 경우 main 이라는 이름의 쓰레드가 실행된다. 실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰 레드는 종료된다. 웹

HTML 페이지의 경우 지금까지 설명했던 것 처럼 4xx, 5xx와 같은 오류 페이지만 있으면 대부분의 문제를 해결할 수 있다.그런데 API의 경우에는 생각할 내용이 더 많다. 오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는

일반적으로 사용하는 HTML Form을 통한 파일 업로드를 이해하려면 먼저 폼을 전송하는 다음 두 가지 방식의 차이를 이해해야 한다.HTML 폼 전송 방식 application/x-www-form-urlencoded multipart/form-data이 방식을 사용하려

데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버에 개발된 데이터베이스 사용 코드도 함께 변경해야 한다.개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야한다.이런 문제를 해결하기 위해 JDB

이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다.DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 한다. 진짜 문제는 고객이 애플리케이션을 사용할 때, SQL을 실행하는 시간 뿐만

데이터를 저장할 때 단순히 파일에 저장해도 되는데, 데이터베이스에 저장하는 이유는 무엇일까?여러가지 이유가 있지만, 가장 대표적인 이유는 바로 데이터베이스는 트랜잭션이라는 개념을 지원하기 때문이다.트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서 이

여러가지 애플리케이션 구조가 있지만, 가장 단순하면서 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 것 이다.프레젠테이션 계층UI와 관련된 처리 담당웹 요청과 응답사용자 요청을 검증주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC서비스 계층비즈

들어가기 앞서 DTO(data transfer object) 데이터 전송 객체 DTO는 기능은 없고 데이터를 전달만 하는 용도로 사용되는 객체를 뜻한다. 참고로 DTO에 기능이 있으면 안되는가? 그것은 아니다. 객체의 주 목적이 데이터를 전송하는 것이라면 DTO라

데이터 접근 기술에 대해서 더 알아보기 전에 데이터베이스에 연동하는 테스트에 대해서 알아보자. 데이터 접근 기술은실제 데이터베이스에 접근해서 데이터를 잘 저장하고 조회할 수 있는지 확인하는 것이 필요하다. 지금부터 테스트를 실행할 때 실제 데이터베이스를 연동해서 진행해

MyBatis 소개MyBatis는 앞서 설명한 JdbcTemplate보다 더 많은 기능을 제공하는 SQL Mapper 이다.기본적으로 JdbcTemplate이 제공하는 대부분의 기능을 제공한다.JdbcTemplate과 비교해서 MyBatis의 가장 매력적인 점은 SQL

ORM Object-relational mapping(객체 관계 매핑) 객체는 객체대로 설계 관계형 데이터베이스는 관계형 데이터베이스대로 설계 ORM 프레임워크가 중간에서 매핑 대중적인 언어에는 대부분 ORM 기술이 존재 JPA는 애플리케이션과 JDBC 사이에서 동작

build.gradle - 의존관계 전체spring-boot-starter-data-jpa 는 spring-boot-starter-jdbc 도 함께 포함(의존)한다. 따라서 해당 라이브러리 의존관계를 제거해도 된다. 참고로 mybatis-spring-boot-start

CRUD + 쿼리동일한 인터페이스페이징 처리메서드 이름으로 쿼리 생성스프링 MVC 에서 id 값만 넘겨도 도메인 클래스로 바인딩코딩량도메인 클래스를 중요하게 다룸 비지니스 로직 이해 쉬움더 많은 테스트 케이스 작성 가능진짜 편함. 과거로 돌아가라면 ...비지니스 로직에

•QUERY는 문자, Type-check 불가능•실행하기 전까지 작동여부 확인 불가•컴파일 에러 (좋은 에러)•런타임 에러 (나쁜 에러)•만약 SQL이 클래스처럼 타입이 있고 자바 코드로 작성 할 수 있다면? •type-safe•컴파일시 에러 체크 가능 •Code-as

중간에서 JpaItemRepositoryV2 가 어댑터 역할을 해준 덕분에 ItemService 가 사용하는ItemRepository 인터페이스를 그대로 유지할 수 있고 클라이언트인 ItemService 의 코드를 변경하지 않 아도 되는 장점이 있다.고민구조를 맞추기

지금까지 학습한 스프링 트랜잭션을 간략히 복습하면서 정리해보자.각각의 데이터 접근 기술들은 트랜잭션을 처리하는 방식에 차이가 있다. 예를 들어 JDBC 기술과 JPA 기술은 트랜잭션 을 사용하는 코드 자체가 다르다.JDBC 트랜잭션 코드 예시 JPA 트랜잭션 코드 예시

실행하기 전에 트랜잭션 관련 로그를 확인할 수 있도록 다음을 꼭! 추가하자. @TestConfiguration : 해당 테스트에서 필요한 스프링 설정을 추가로 할 수 있다. DataSourceTransactionManager 를 스프링 빈으로 등록했다. 이후 트랜잭션

V1은 member를 엔티티로 받았지만 V2는 DTO로 받았다.RequestDTO ResponseDTO를 스펙에 맞게 만들자업데이트시 서비스에서 그냥 쿼리를 짠다.Result로 감싸줘야한다.(Collection 그대로 나가면 문제가 생김)