# springMVC

pp8817

✏️ 검증1 - Validation에서 검증 기능을 소개했다.(왜인지 모르겠지만 글이 날라갔다.. 추후에 다시 작성해야할 것 같다.) 검증 기능을 지난 글에서 소개한 것처럼 매번 코드로 작성하는 것은 상당히 번겁롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다. 이런 검증 로직을 모든 프로젝트에 적용할 수 있게 공통화하고, 표준화 한 것이 바로 Bean Validation이다. Bean Validation을 잘 활용하면, 애노테이션 하나로 검증 로직을 매우 편리하게 적용할 수 있다. 의존관계 추가 build.gradle Bean Validation을 사용하려면 위의 의존관계를 추가해야 한다. 테스트 코드 실행 결과 > 출력 결과를 보면, 검증 오류가 발생한 객체, 필드

s2hoon

2. 서블릿 스프링부트 서블릿 사용법 스프링 부트는 톰캣 서버를 내장하고 있으므로, 톰캣 서버 설치 없이 편리하게 서블릿 코드를 실행할 수 있다. Main 함수에 @ServletComponentScan 추가후 @WebServlet 등록 HTTP 요청 데이터 HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 방법을 알아보자. 주로 다음 3가지 방법을 사용한다. GET - 쿼리 파라미터 /url?username=hello&age=20 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달 예) 검색, 필터, 페이징등에서 많이 사용하는 방식 POST - HTML Form content-type: application/x-www-form-urlencoded 메시지 바디에 쿼리 파리미터 형식으로 전달 username=hello&age=20 예) 회원 가입, 상품 주문, HTML Form 사용 **HTTP m

s2hoon

웹 서버, 웹 애플리케이션 서버 HTTP 대다수의 시스템이 통신 할 때는 HTTP 메시지에 모든 것을 포함하여 전송한다. HTTP 에는 HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON ,XML 등등 거의 모든 형태의 데이터 전송이 가능하다. HTTP 시대!! 웹 서버(Web Server) HTTP 기반으로 동작하며, 정적 리소스를 제공한다. (HTML,CSS, JS, 이미지 영상 등) NGINX, APACHE 등이 이에 해당한다. 웹 애플리케이션 서버(WAS - Web Application Server) HTTP 기반으로 동작하며, 웹 서버의 기능(정적 리소스제공) 을 포함하면서, 동적 리소스(서블릿, JSP, 스프링 MVC등)를 제공하고, 애플리케이션 로직을 수행한다. 자바에서는 서블릿 컨테이너를 WAS 라고 한다. Tomcat 이 이에 해당한다. 웹 시스템 구성 WAS 가 너무 많은 역할을 담당하면, 서버

sangyunpark

스프링 MVC - 예외처리 상당히 중요한 파트이다! 예외란 > 프로그램이 예상치 못한 상황을 만났을 때 오류를 발생시키는 것(throw new Exception()) 일반적인 자바 프로그램이 예외를 처리하는 방법 스프링 MVC에서 예외처리를 활용하는 방법(REST API용) > @ExceptionHandler 컨트롤러 기반 예외 처리 HTTP Status code를 변경하는 방법 HTTP Status code를 변경하는 방법 @ResponseStatus ResponseEntity활용 예외처리 우선순위 해당 Exception이 정확히 지정된 Handler 해당 Exception의 부모 예외 Handler 이도 저도 아니면 그냥 Exception(모든 예외의 부모) ErrorResponse Dto ResponseEntity를 활용한 응답 상태코드, 헤더 등등 세부적으로 조절이 가능하

sangyunpark

필터와 인터셉터의 차이 필터 스프링 외부의 서블릿에서 제공하는 공통처리 기능 스프링 내로 요청이 들어오기 전과 스프링의 요청이 나갈 때 처리 가능 조금 더 low level 처리가 가능 좋은 레스토랑에 처음 들어갈 때 옷에 묻은 먼지를 털듯 제일 앞에서 필터링 해주는 곳 인터셉터 스프링에서 제공하는 공통처리 기능 실제 매핑된 Handler 정보 확인 가능(어떤 것이 실제 내 요청을 처리하는지도 확인 가능) 조금 더 상세한 조건식과, 세부적인 스펙(pre, post, after)를 통해 구체적인 시점에 구체적인 동작 가능 AOP와 비교한다면 AOP는 인터셉터보다 더 구체적인 조건(애노테이션, 파라미터, 주소 등)과 동작 위치(afterThrowing)을 갖음

sangyunpark

MVC 패턴 M(Model), V(View), C(Controller) Model : 로직 안에서 이동하고 있는 데이터 View: 화면은 화면의 역할만 한다. Controller: 비즈니스 로직을 처리하고 모델과 뷰를 응답으로 준다. Spring MVC - HTTP 요청 / 응답 스프링 MVC 프로젝트 생성 스프링 MVC 기본 HTTP 요청 매핑 Controller/RestController의 차이 Controller : 응답값이 기본적으로 HTML을 주도록 되어 있음 RestController : 응답값으로 Rest API 요청에 대한 응답(주로 JSON)을 주도록 되어 있음 매핑 어노테이션 @RequestMapping : G

kkkkkksssssaaaa

안녕하세요:) 영한님의 스프링 핵심 원리 고급편 실습을 진행하다 마주하게된 오류에 대해 파헤쳐본(?) 경험을 공유하려 합니다. > 우선, 실습에서는 SpringBoot 2.5.5 버전을 사용 하고 있지만, 저는 3.0.7 버전을 사용하여 실습 프로젝트를 생성하여 진행 하고 있습니다. 버전을 다르게 사용한 이유는 최신 버전을 사용하며 달라진 점이 있다면 이 것을 찾아가며 공부하면 도움이 되겠다! 라는 생각 때문이었어요. > 그렇게 강의를 보며 실습 하던 도중, @RequestMapping, @Controller 둘 중 하나만 사용해도 스프링이 알아서 핸들러 클래스임을 인식해준다는 새로운 사실을 알게 되었습니다 🫢 실습에서는 빈 자동 등록 대상인 @Controller 대신, 자동 등록 대상에서 제외된 @RequestMapping 을 사용하여 수동으로 등록하는 것으로 진행 되었습니다. 그래서 실습대로 @RequestMapping 만 사용하여

jeongm2n

첫 깃허브 Merge Conflict 발생..! 2023.08.05 (첫 merge 충돌난 기념으로 작성...) 10번 정도의 Merge 동안 한 번도 conflict가 발생하지 않아서 좀 방심하고 있었다.. 심지어 멘토링 시간에 멘토님들에게 깃허브 병합 때 충돌 예방하는 방법이 있나요? 라는 질문에 그런건 없고 팀원끼리 의사소통 잘 해서 최대한 충돌 없게 세세하게 확인하는 수 밖에 없다는 말을 들은지 30분만에 발생한 Conflict 였다..!ㅠ >_ 문제 :_ 잘 되던 Merge에서 Conflict 발생..!! > 개발 환경 : GitHub에서 master 브랜치를 복제한 develop 개발 브랜치를 만들고 develop을 default로 팀원들 각자의 개인 브랜치를 생성하여 각자 브랜치에서 코딩 후 push 해서 develop에서 merge한

hoyo1744

Spring 스프링에서는 웹과 관련된 공통 관심 사항을 처리할 수 있도록 지원하는 서블릿 필터와 스프링 인터셉터 기술이 존재한다고 한다. AOP를 사용해도 되지만 웹과 관련된 공통 관심 사항에서는 Http 헤더나 Url 정보 등이 필요하기 때문에 필터나 인터셉터를 사용하게 좋다고 한다. 필터나 인터셉터는 HttpServletRequest와 HttpServletResponse를 제공하기 때문! 서블릿 필터 필터는 서블릿이 지원하는 수문장 역할을 수행한다고 한다. 필터의 실행 흐름은 아래와 같다. > HTTP 요청 -> WAS -> 필터 -> 서블릿(디스패처 서블릿) -> 컨트롤러 필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다. 그밖에도 여러개의 필터를 체인 형식으로도 지원이 가능하다고 한다. > HTTP 요청 -> WAS -> 필터1 -> 필터2 -> 필터3 -> 서블릿 -> 컨트롤러 실제 필터 인터페이스 코드는 아래와 같다. 필터 인터페이스를 구현하

hoyo1744

Spring 쿠키 로그인 상태를 유지하기 위해서는 쿠키를 사용할 수 있다. 쿠키를 사용하지 않는다면 로그인 정보를 매번 Request Parameter로 전달해야한다. 특히, 쿠키의 종류는 영속 쿠키와 세션 쿠키가 있다고 한다. 영속 쿠키 : 만료 날짜를 입력 하면 해당 날짜까지 유지 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지 아래의 코드는 쿠키를 이용해서 로그인 정보를 클라이언트에게 전달하는 코드의 예시이다. 쿠키를 생성하고 HttpSevletResponse 객체에 쿠키를 추가해서 클라이언트에게 전달한다. 아래의 코드는 @CookieValue 애노테이션을 사용해서 쿠키를 쉽게 조회할 수 있다. required = false는 반드시 필요하지 않음을 의미한다. homeLogin 컨트롤러가 호출되면 쿠키값을 파싱해서 알아서 Long memberId에 바인딩된다. 실제로 쿠키를 제거할떄는 SetMaxAge(0)으로 설정해주면 된다.

hoyo1744

Spring Bean Validation Spring에서는 객체에 대해서 Validation을 수행하는 매우 편리한 방법을 제공한다. 이전 포스팅에서는 BindingResult와 Validator, 그리고 @Validated 애노테이션을 사용한 Validation 방식을 공부했었다. 이전 포스팅 : Spring에서 Validation 그런데 Controller 기준이 아니라 특정 객체를 기준으로 Validation을 수행한다면 같은 코드가 반복될 확률이 높다. 그렇다면 Validation 코드가 반복되고 여기저기에서 사용될것이다. 이러한 문제를 해결하기 위해서는 스프링에서 Validation 로직을 공통화할 수 있도록 제공한다. 위 코드에서 사용된 @NotNull, @NotBlank, @Max(), @Rag

bkj0326

11. 파일 업로드 1. 파일 업로드 소개 > 일반적으로 사용하는 HTML Form을 통한 파일 업로드를 이해하려면 먼저 폼을 전송하는 다음 두 가지 방식의 차이를 이해해야 한다. HTML 폼 전송 방식 application/x-www-form-urlencoded multipart/form-data application/x-www-form-urlencoded 방식 application/x-www-form-urlencoded 방식은 HTML 폼 데이터를 서버로 전송하는 가장 기본적인 방법이다. Form 태그에 별도의 enctype 옵션이 없으면 웹 브라우저는 요청 HTTP 메시지의 헤더에 다음 내용을 추가한다. `Content-Type: appli

bkj0326

10. 스프링 타입 컨버터 1. 스프링 타입 컨버터 소개 > 문자를 숫자로 변환하거나, 반대로 숫자를 문자로 변환해야 하는 것 처럼 애플리케이션을 개발하다 보면 타입을 변환해야 하는 경우가 상당히 많다. 스프링의 타입 변환 적용 예 스프링 MVC 요청 파라미터 @RequestParam, @ModelAttribute, @PathVariable @Value등으로 YML 정보 읽기 XML에 넣은 스프링 빈 정보를 변환 뷰를 렌더링 할 때 스프링과 타입 변환 스프링이 중간에 타입 변환기를 사용해서 타입을 String -> Integer로 변환해주었기 때문에 개발자는 편리하게 해당 타입을 바로 받을 수 있다. 문자를 숫자로, 숫자를 문자로, Boolean타입을 숫자로 변경하는 것도 가능하다. 컨터버 인터페이스 스프링은 확장 가능한 컨버터 인터페이스를 제공한다. 개발자는 스프링에 추가적인 타입

hoyo1744

Spring BindingResult Spring에서는 BindingResult 객체를 이용해서 검증 오류를 보관하는 기능을 제공한다. 즉, Controller에서 특정 객체에 대해서 검증 오류가 발생하면 BindingResult객체에 담기게 된다. BindingResult의 간단한 사용 예시는 아래와 같다. BindingResult는 위 코드에서 Item 객체에 대한 검증 오류 결과가 저장된다. 다만, 주의해야할점이 있는데, BindingResult는 ModelAttribute 바로 뒤에 위치해야한다고 한다. 그렇다면 굳이 BindingResult를 써야하는 이유가 뭘까? 별도의 Map 컬렉션을 사용해도되지 않을까? BindingResult를 사용함으로써 아래와 같은 이점을 얻을 수 있다. > ModelAttribute 애노테이션을 이용해서 객체를 바인딩할때, 타입 오류에 대한 처리를 자동으로 해준다. **BindingResult를 사용하는

bkj0326

8. 예외 처리와 오류 페이지 1. 서블릿 예외 처리 - 시작 > 스프링이 아닌 순수 서블릿 컨테이너는 예외를 어떻게 처리하는지 알아보자. 서블릿은 다음 2가지 방식으로 예외 처리를 지원한다. Exception(예외) response.sendError(HTTP 상태 코드, 오류 메시지) Exception(예외) 자바 직접 실행 자바의 메인 메서드를 직접 실행하는 경우 main이라는 이름의 쓰레드가 실행된다. 실행 도중에 예외를 잡지 못하고 처음 실행한 main()메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다. 웹 애플리케이션 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그런데 애플리케이션에서 예외를 잡지 못하고, 서블릿

bkj0326

4. 검증 1. Validation 1. 검증 요구사항 > 상품 관리 시스템에 검증 로직 추가 타입 검증 가격, 수량에 문자가 들어가면 검증 오류 처리 필드 검증 상품명: 필수, 공백X 가격: 1000원 이상, 1백만원 이하 수량: 최대 9999 특정 필드의 범위를 넘어서는 검증 가격 * 수량의 합은 10,000원 이상 클라이언트 검증, 서버 검증 클라이언트 검증은 조작할 수 있으므로 보안에 취약. 서버만으로 검증하면, 즉각적인 고객 사용성이 부족. 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수. API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 함. 2. 검증 직접 처리 검증 오류 보관 Map errors = new HashMap(); 검증 로직 오류가 발생

hoyo1744

Spring @Controller @Controller 애노테이션을 이용해서 RequestMappingHandler를 만들게 되면 자동으로 컴포넌트스캔에 의해서 자동으로 스프링빈에 등록되어서 RequestMappingHandler와 RequestMappingHandlerAdapter에 의해서 컨트롤러가 호출될 수 있다고 했다. 그밖에도 @Controller 애노테이션을 활용한 컨트롤러는 다양한 인자를 제공할 수 있으며, 자세한 내용은 아래의 가이드 페이지에서 확인할 수 있다. @Controller에서 사용할수 있는 인자들 이전 공부했었던 내용으로 몇가지 예시를 들면 아래와 같다. 위 코드를 postman으로 아래와같이 요청했을때의 수행결과는 다음과 같다. ![](https:/

bkj0326

1. 타임리프 - 기본 기능 1. 타임리프 특징 서버 사이드 HTML 렌더링(SSR) 네츄럴 템플릿 스프링 통합 지원 > 공식 사이트 공식 메뉴얼 - 기본 기능 [공식 메뉴얼 - 스프링 통합](https://www.thymeleaf.org/doc/tutorials/3.0/thymeleafspring.html ) 2. 기본 표현식 > 참고 간단한 표현: 변수 표현식: ${...} 선택 변수 표현식: *{...} 메시지 표현식: #{...} 링크 URL 표현식: @{...}

hoyo1744

Spring springMVC war 패키징과는 달리 jar 패키징을 사용하게 되면 /resources/static/index.html 위치에 index.html을 두면 welcome page로 처리해준다. war 패키징을 사용하면 webapps 하위 경로를 사용했었다. @Controller @Controller 애노테이션을 사용하면 컨트롤러(핸들러)가 컴포넌트스캔의 대상이 되어서 스프링빈으로 등록된다. @Controller내부에는 @RequestMapping과 @Component의 조합으로 구성된다. 따라서, @Controller가 붙은 클래스는 return 값은 뷰 이름으로 지정된다. @RestController @Controller와 달리 @RestController가 붙은 클래스에서의 리턴값은 Http 메시지 바디에 바로 입력된다. log4j 사용시 주의사항 log4j를 이용해서 로깅을 하는 경우 아래와같이 사용하지 말아야한다. +연산

hoyo1744

Spring Spring MVC 스프링은 애노테이션 기반의 컨트롤러를 만드는데 @RequestMapping 애노테이션을 사용한다. @RequestMapping 애노테이션이 있으면 RequestMappingHandlerMapping, RequestMappingHandlerAdapter가 사용되어 핸들러(컨트롤러)가 호출된다. Spring MVC에서의 컨트롤러 코드는 아래와 같다. ModelAndView는 말그대로 Model(Map객체)와 논리적인 View를 갖고 있는 객체다. 나중에 ModelAndView는 뷰리졸버를 통해서 실제 물리적 뷰 경로를 갖고 있는 View객체가 반환되고, View 객체의 render 함수를 통해서 thymeleaf나 jsp로 제어권을 넘긴다. @Controller : 이 애노테이션이 있으면 스프링이 자동으로 스프링빈으로 등록한다. 내부에 @Component 애노테이션이 있어 컴포넌트 스캔의 대상이 된다. 그리고 스프링 MVC에서 애노테