look-forest

쿠키와 세션을 활용해서 로그인 기능을 구현해보자. ※ 패키지 구조 설계도메인이 가장 중요하다. 향후 web을 다른 기술로 바꾸어도 도메인은 그대로 유지할 수 있어야 한다.예를 들어 web 패키지를 모두 삭제해도 domain에는 전혀 영향이 없도록 의존관계를 설계하는 것이 중요하다.즉 web은 domain을 의존하지만, domain은 web을 의존하지 않도록 설계해야 한다. domain은 web을 참조하면 안된다. 1. 로그인이 되면 홈 화면에 고객 이름이 보여야 한다는 요구사항 - 쿠키 사용서버에서 로그인에 성공하면 HTTP 응답에 쿠키를 담아서 브라우저에 전달하자.그러면 브라우저는 앞으로 해당 쿠키를 지속해서 보내준다. 쿠키에는 영속 쿠키와 세션 쿠키가 있다.영속 쿠키: 만료 날짜를 입력하면 해당 날짜..

검증 기능을 매번 코드로 작성하는 것은 상당히 번거롭다.특히 특정 필드에 대한 검증 로직은 대부분 빈 값인 지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다즉, 정형화 할 수 있다.이런 검증 로직을 애노테이션을 활용해 모든 프로젝트에 적용할 수 있게 공통화, 표준화 한 것이 바로 Bean Validation이다.※ 여기서 말하는 Bean은 Spring Bean이 아니라 Java Bean이다. (캡슐화를 통해 데이터와 메소드를 하나의 객체로 묶는 형태. 주로 getter/setter를 통해 필드 접근)Bean Validation 적용spring-boot-starter-validation 의존관계를 추가하면 Bean validation을 사용할 수 있다. 기존에 만든 validator는 ..

고객이 입력한 값을 검증할 필요가 있다.클라이언트 검증은 조작할 수 있으므로 보안에 취약하다 (postman만 써봐도 우회가 가능)서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다.=> 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수 먼저 검증을 직접 구현해보고, 뒤에서 스프링과 타임리프가 제공하는 검증 기능을 활용해보자 version1. 순수 검증 직접 구현 검증 로직 에러 메시지를 모델에 담아 뷰로 보내고, 뷰에서 처리한다. 화면 처리 화면 처리 시 고객이 이전에 입력한 데이터가 보이는 이유는, 애초에 객체를 보내도록 설계했기 때문이다.  문제는 중복이 너무 많고, 번거롭다는 것과타입 검증이 불가하다는 것이다. 타입 오류는 컨트롤러에 오기 전에 바인딩 오류가 발생해서 400에러가 발생..

서버 사이드 HTML 렌더링(SSR) 언어인 타임리프에 대하여 정리해보겠다.참고spring-boot-devtools 라이브러리를 추가하면, html 파일을 컴파일만 해주면 서버 재시작 없이 View 파일 변경이 가능하다. (인텔리J 컴파일 방법: 메뉴 build Recompile)타임 리프 특징서버 사이드 HTML 렌더링(SSR)내추럴 템플릿: 타임리프로 작성한 파일은 HTML을 유지하기 때문에 웹 브라우저에서 파일을 직접 열어도 내용을 확인할 수 있고, 서버를 통해 뷰 템플릿을 거치면 동적으로 변경된 결과를 확인할 수 있다스프링 통합 지원 타임 리프 기본 기능타임리프 사용 선언 기본 표현식 정리  텍스트 출력 - th:text / utext기본 사용 : 컨텐츠 안에서 직접 출력 : [[${data}]]..

애플리케이션에서 데이터베이스에 접근할 때 사용하는 JDBC라는 기술에 대하여 알아보자. JDBC 등장 이유일반적으로 애플리케이션 서버에서 데이터베이스를 사용할 때는 아래 과정을 거친다. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결SQL 전달: 애플리케이션 서버는 SQL을 연결된 커넥션을 통해 DB에 전달결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답. 애플리케이션 서버는 응답 결과를 활용 문제는,각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다는 것이다.-> 데이터베이스를 변경하면 애플리케이션 서버에 개발된 DB 사용 코드도 함께 변경해야 하며, 각각 학습해야 한다. 이런 문제를 해결하기 위해 JDBC라는 자바 ..

POST 요청을 통해 데이터를 등록하고, 새로고침하면 심각한 문제가 발생할 수 있다. PRG : Post/Redirect/GetPOST로 데이터를 레파지토리에 저장 후, 응답이 다음과 같은 상황이다. 새로고침은 "마지막에 요청한 행위를 다시 하는 것"이다.그래서 등록 요청을 반복하게된다. 따라서 '마지막에 요청한 행위'를 POST가 아닌 GET으로 바꿔줘야 하는 것이다.이런 문제 해결 방식을 PRG (Post/Redirect/Get) 라 한다.  POST 요청을 리다리엑트로 응답받아 GET 요청을 하게 한다.  ※ 주의"redirect:/basic/items/" + item.getId() redirect에서 +item.getId() 처럼 URL에 변수를 더해서 사용하는 것은URL 인코딩이 안되기 때문에 ..

뷰 템플릿으로 HTML을 생성해 응답하는 것이 아니라, HTTP API처럼 JSON, String 등을 body에 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터가 동작한다. HttpMessageConverter HTTP 메시지 body에 JSON을 직접 반환하는 경우, ViewResolver 대신에 HttpMessageConverter가 동작한다. Spring MVC는 다음의 경우에 HttpMessageConverter를 적용한다. HTTP 요청 : @RequestBody, HttpEntity (RequestEntity) HTTP 응답 : @ResponseBody, HttpEntity (ResponseEntity) HttpMessageConverter 인터페이스 package org.springframe..

스프링에서 응답 데이터를 만드는 방법 정적 리소스 뷰 템플릿 HTTP 메시지 HTTP 응답 - 정적 리소스, 뷰 템플릿 (HTML) 정적 리소스 src/main/resources 는 리소스를 보관하는 곳이자 classpath의 시작 경로 스프링 부트는 classpath의 다음 디렉토리에 있는 정적 리소스 제공 /static /public /resource /META_INF/resources 뷰 템플릿 뷰 템플릿을 거쳐 HTML이 생성되고, 뷰가 응답을 만들어 전달한다. 스프링 부트가 기본 제공하는 뷰 템플릿 경로은 다음과 같다. src/main/resources/templates HTTP API - 메시지 바디에 직접 입력 HTTP 응답 메시지 바디에 HTML이 아니라 문자, JSON 등 데이터를 입력하..