스프링 MVC

우리는 일단 client와 client, client와 서버 모든것을 HTTP를 기반으로 통신한다.간단하게 HTTP가 뭐냐면, 뭐 client와 서버끼리 무언가 주고받고싶다고 치자, 그러면 client가 전달한 무언가를 보고 서버가 해석을 할 수 있어야 어떤 비즈니스

우선 서블릿을 사용하려면 스프링 부트가 지원하는 서블릿 컴포넌트 스캔을 사용해야 한다.왜 사용해야되냐? URL 요청이 들어오면 해당 서블릿을 찾아야하는데 서블릿 컨테이너에 서블릿을 등록해놓고, 여기서 찾기 위해서이다.스프링부트는 직접 서블릿을 등록 및 사용할 수 있도록

이번시간부터 어떻게 MVC 패턴이 나왔는지,서블릿->MVC 순으로 어떻게 점차 발전해왔는지 알아보겠다.회원정보이름: username나이: age기능 요구사항회원 저장회원 목록 조회회원 도메인 모델회원저장소우선 회원 저장에 쓰일 Map과 sequence 필드를 만들어 준

프론트 컨트롤러 패턴 소개프론트 컨트롤러 도입전에는 이전 포스팅과 같이 유저가 요청을 서버로 보내면, 해당하는 서블릿에서 로직이 수행되었다.그렇기 때문에 공통로직을 처리해야하면, 서블릿 컨테이너에 있는 모든 서블릿에 각각 공통처리 로직이 들어가 있어야 했다.프론트 컨트

우선 RestController로 등록해주었다. 일단, RestController내부에 컨트롤러 애노테이션이 있어서 디스페쳐 서블릿이 핸들러 맵핑할때 RequestMappingHandlerMapping에서 컨르롤러 인식해서 맵핑해준다.어쨋든, RestController

서비스 제공흐름검은색 박스가 컨트롤러 흰색 박스가 뷰이다.즉 항상 뷰를 컨트롤러를 통해 접근해야한다.항상 상품 목록에서 시작해서 상품 등록 폼, 상품 상세페이지->상품 수정 폼으로 이동하도록 설계했다.상품에는 상품 id와 이름, 가격 수량을 설정했다.가격과 수량에는

addform.htmleditform.htmlitem.htmlitems.html

우선 validation에대해서 짚고 넘어가야 할것이 있다. 우선 validation은 뒷단보다는 프론트에서 넘기는것이 일단 맞다. 왜냐하면, 서버측에서 검증이 불가능한게 아니라, 서버측에서 검증을 받기위해서는 일단 클라이언트가 요청을 서버측으로 날리고, 그다음에 서

로그인 방식에는 쿠키와 세션을 이용하는방식 JWT를 사용하는방식이 있다. JWT에 대한 글은 이 글을 보면된다.도메인에서 중요한것은 도메인 영역에는 화면, UI, 기술 인프라 등등의 영역을 제외한 시스템이 구현해야하는 핵심 비즈니스 영역을 설정해야한다.왜냐하면 web을

이번시간에는 지난시간의 세션과 쿠키를 사용한 로그인 처리 이후, 필터와 인터셉터를 배워보도록 하겠다. 필터와 인터셉터를 사용하는이유가, 지난 시간 글의 마지막에 설명했지만, 로그인을 하지 않더라도 URL로 get요청을 보내면 response를 받을 수 있다는것이다.

스프링이 아닌 순수 서블릿 컨테이너는 예외를 Exception, response.sendError 이 두가지 방식으로 처리한다.Exception(예외)웹 애플리케이션에서는 사용자의 요청별로 쓰레드가 별도로 할당되고, 서블릿 컨테이너 안에서 실행된다.만약에 오류가 터졌는

문자를 숫자로, 숫자를 문자로 변환해야하는 경우가 상당히 많다.그러나 이걸 Integer.valueOf로 변환하는게 귀찮다.@RequestParam을 사용하면 자동적으로 Integer 해당 type으로 캐스팅해준다.이것처럼 URL경로, 쿼리파라미터, 스프링 MVC요청

웹 애플리케이션 이해client와 client, client와 server 모든 것을 HTTP 기반으로 통신한다.HTTP: 요청과 응답을 인터넷상에서 어떻게 주고받을지 정의한 규약웹서버 vs 웹 애플리케이션 서버웹서버http기반으로 동작정적 리소스 제공정적 파