검증 로직을 공통화 및 표준화하여 애노테이션으로 적용할 수 있게 함Bean Validation 2.0(JSR-380)이라는 기술 표준검증 애노테이션과 여러 인터페이스의 모음jakarta.validation-api : Bean Validation 인터페이스hibernat

타입 검증가격, 수량에 문자 허용하지 않음필드 검증상품명: 필수, 공백X가격: 1,000원 이상 ~ 1,000,000원 이하수량: 최대 9999개특정 필드의 범위 검증가격 \* 수량의 합은 10,000원 이상검증 오류 발생 시, Map(errors)에 해당 정보 담아두

label 등 다양한 메시지를 한 곳에서 관리하는 기능messages.properties각 HTML에서 해당 데이터를 key 값으로 사용th:text=메시지 파일을 언어/국가별로 별도 관리하여 메시지 국제화 가능messages_en.propertiesMessageSou

스프링 SpringEL 문법 통합스프링 빈 호출 지원${@myBean.doSomething()}편리한 폼 관리 속성 지원th:object, th:field, th:errors, th:errorclass 등폼 컴포넌트 기능스프링 메시지, 국제화 기능 통합스프링 검증, 오

서버 사이드 HTML 렌더링 (SSR)백엔드 서버에서 HTML을 동적으로 렌더링하기 위해 사용내츄럴 템플릿(Natural Templates)순수 HTML을 최대한 유지하면서 뷰 템플릿도 사용할 수 있음스프링 통합 지원스프링의 다양한 기능을 편리하게 사용할 수 있도록 지

상품 ID상품 명상품 가격상품 수량상품 목록상품 상세상품 등록상품 수정Item 상품 객체(VO)ItemRepository 상품 저장소상품 등록, 상품 조회, 전체 상품 조회, 상품 수정상품 서비스 HTMLitems.html 전체 상품 조회item.html 상품 조회ad

@RestController반환 값으로 뷰가 아니라 HTTP 메시지 바디에 바로 입력@RequestMapping("/매핑경로")매핑 경로는 배열\[]로 다중 설정 가능({"/mapping1", "/mapping2"})메서드 속성을 지정하지 않으면 모두 허용(GET, P

스프링 부트에서는 로깅 라이브러리(spring-boot-starter-logging)를 기본으로 포함SLF4J (로그 인터페이스)Logbackprivate Logger log = LoggerFactory.getLogger(getClass());private static

DispatcherServlet (=프론트 컨트롤러)DispatcherServlet > FrameworkServlet > HttpServletBean > HttpServlet 상속서블릿이 호출되면 HttpServlet.service() 호출service()를 오버라이드

서블릿 하나로 클라이언트의 모든 요청을 받음요청에 맞는 컨트롤러를 찾아서 호출공통 처리 가능다른 컨트롤러는 서블릿을 사용하지 않아도 됨cf. 스프링 웹 MVC의 DispatcherServlet이 프론트 컨트롤러 패턴으로 구현됨urlPatterns = "/front-co

서블릿자바 코드로 HTML Form을 만들어서 응답해야 함복잡하고 비효율적템플릿 엔진JSP, Thymeleaf, velocity 등HTML 코드에서 자바 코드를 사용하여 동적으로 만들어 낼 수 있음JSP<%@ \~~ %> : import문<% \~~ %> :

@ServletComponenScan : 서블릿 자동 등록@WebServlet : 서블릿 어노테이션name : 서블릿 이름urlPatterns : URL 매핑서블릿은 HTTP 요청 메시지를 편리하게 사용할 수 있도록 파싱한 후 HttpServletRequest 객체로

웹 서버, 웹 애플리케이션 서버 웹은 HTTP 기반 HTTP 메시지에 모든 것을 전송함(HTML,TEXT, 이미지, 영상, JSON 등) 웹 서버 (Web Server) HTTP 기반 동작 정적 리소스 제공 (HTML, CSS, JS, 이미지, 영상 등) 웹 애플리

웹 애플리케이션 이해웹 서버, 웹 애플리케이션 서버서블릿멀티 쓰레드HTML, HTTP API, CSR, SSR자바 백엔드 웹 기술 역사서블릿HttpServletRequest, HttpServletResponseGET, POST, API서블릿, JSP, MVC패턴MVC

빈이 존재할 수 있는 범위스코프 종류싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지프로토타입스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관여함(관리,소멸 X)요청 시마다 항상 새로운 인스턴스를 생성하여 반환많이 사용하지는 않음웹

데이터베이스 커넥션풀이나 네트워크 소켓과 같이 애플리케이션 초기화와 종료 작업이 필요한 경우스프링 빈의 이벤트 라이프사이클스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 종료cf. 객체의 생성과 초기화

생성자 주입: 일반적으로 주입하는 방법생성자 호출 시점에 한 번만 실행생성자가 1개인 경우, @Autowired 생략해도 자동 주입됨(스프링 빈인 경우)불변, 필수인 의존관계에 사용사용 권장 -> 대부분 의존관계 주입은 변경할 일이 없음, final 키워드 사용 가능c

설정 정보에 @ComponentScan 어노테이션을 붙임 컴포넌트 스캔을 사용하면 @Configuration이 붙은 설정 정보(ex. AppConfig)도 자동으로 등록되기 때문에 excludeFilter로 제외해야 함@Component가 붙은 클래스를 모두 스캔하여

순수한 DI 컨테이너는 요청할 때마다 새로운 객체를 생성함 -> 메모리 낭비싱글톤 패턴은 클래스의 인스턴스를 하나만 생성하여 공유하는 디자인 패턴싱글톤 패턴 적용 방법싱글톤 패턴의 문제점싱글톤 패턴을 구현하는 코드가 많아짐구체 클래스에 의존함 -> DIP 위반 -> O

일반적으로 ApplicationContext(interface)를 말함자바 설정 클래스(어노테이션 기반) XML 기반스프링 컨테이너 생성(AppConfig.class)스프링 빈 등록 \*빈 이름은 모두 달라야 함스프링 빈 의존관계 설정 준비스프링 빈 의존관계 설정 완료