
(참고: Spring Boot와 Thymeleaf, IntelliJ를 기준으로 작성된 글입니다) 이전 글(Validation)에서 살펴보았던 Validation의 경우 코드를 직접 작성하여 테스트하였는데 검증이란 것이 특정 서비스에서만 적용이 되는 것이 아닌 만국 공통의 개념인 만큼 스프링 프레임워크가 이를 제공하는데 여기서 더 나아가 애노테이션 기반의 검증기인 Bean Validation(JSR-380)을 사용할 수 있다 Bean Validation 이란 검증을 매번 코드로 작성하기에는 너무 번거롭다는 단점이 있다, 또한 각 계층별로 검증이 필요하기 때문에 동일한 검증 코드를 작성하게 된다면 구현된 검증 로직 간 불일치로 인하여 오류가 발생할 수도 있다. 여기에 주된 검증의 내용이 빈 값을 검증하거나,..

(참고: Spring Boot와 Thymeleaf를 기준으로 작성된 글입니다.) (참고: 본 글은 Bean Validation을 살펴보기 전 Validation의 기본적인 동작 구조를 살펴보기 위한 글입니다.) Validation, 검증이라는 뜻대로 클라이언트가 보낸 값들을 검증하는 것이다 Validation이 필요한 이유를 비롯하여 어떻게 구현하는지 살펴보고자 한다 Validation이 필요한 이유 클라이언트가 보낸 값들을 검증할 때 클라이언트 사이드에서 JS 등을 사용하여 검증할 수도 있다 하지만 보내는 값을 조작하여 뚫을 수 있는 가능성이 있기 때문에 보안에 취약하다 그렇기 때문에 클라이언트 사이드 검증은 물론 반드시 서버 사이드에서도 데이터를 검증하여야 한다. (적절히 섞어 사용하는것이 제일 좋겠..
(참고: Spring Boot와 Thymeleaf를 기준으로 작성된 글입니다) 상품 페이지 등을 작성하면 공통된 단어들을 사용하는 경우가 빈번하다 (상품명, 상품 가격, 상품 수량 등등의) 만약 이런 요소들이 각각의 페이지에 작성되어 있는데 이를 하나하나 수정하려면 고된 반복 작업이 필요하다 스프링은 이런 작업을 편리하게 하고자 스프링 메시지라는 기능을 제공한다 이번글에서는 스프링 메시지가 무엇인지 어떻게 사용하는 것인지 살펴보고자 한다 Spring Message 스프링은 다양한 메시지를 한 곳에 관리하도록 MessageSource라는 인터페이스를 통하여 메시지 기능을 지원한다 이 기능을 사용하기 위해서는 구현체인 ResourceBundleMessageSource를 아래와 같이 스프링 빈을 등록해야 한다..

PRG패턴이 사용되는 이유와 방법에 대해서 살펴보고자 한다 PRG (Post/Redirect/Get) 패턴이 필요한 이유 만약 사용자가 상품을 구매하는 서비스를 이용하고 있다고 가정해보자 구매 이후에 클라이언트가 실수 혹은 의도적으로 새로고침을 한 경우에 웹 브라우저의 특성상 새로고침은 마지막으로 서버에 전송한 데이터를 다시 전송하게 된다 이때 아래와 같이 설계가 되어 있다면 새로고침 시에 구매 데이터가 한번 더 전송이 되어 중복 구매를 하게 되는 것이다 PRG (Post/Redirect/Get) 패턴 단어 그대로 Post -> Redirect -> Get 패턴으로 만들어지는 것을 PRG 패턴이라고 한다 위의 예시와 같은 상황에서 새로고침을 하였을 경우에 발생하는 문제를 해결하기 위해 사용한다 해결방법은..
(참고 : Spring Boot와 Thymeleaf 기준을 작성된 글입니다) 이전 글(HTTP Request Data)에서 클라이언트가 보낸 요청 값들을 서버 쪽에서 어떻게 조회할 수 있는지 살펴보았다 이렇게 값들을 조회한 후에는 서버쪽에서 해당 로직들을 수행하고 클라이언트에게 응답을 하게 된다 이때 서버쪽에서 어떠한 응답을 어떻게 만드는지 살펴보려고 한다 우선 서버쪽에서 만드는 응답 데이터는 정적 리소스 , 뷰 템플릿, HTTP 메시지와 같이 크게 3가지로 나뉜다 Static Resource(정적 리소스) 웹 브라우저에 정적인 HTML, CSS, JS를 제공할 때 정적 리소스를 사용한다 스프링 부트의 경우 정적 리소스 경로가 설정되어 있는데 src/main/resources/static 경로에 inde..
클라이언트가 서비스를 이용하면 다양한 값들을 서버에 요청할 때 같이 전달하여 서버는 해당 값들을 읽고 요청을 수행한다 어노테이션 기반의 스프링 컨트롤러는 다양한 파라미터를 지원하는데 클라이언트가 요청을 보낼때 서버 쪽에서 다양한 값들을 조회하는 방법을 살펴보고자 한다 required & default value 스프링 어노테이션으로 하나의 값을 조회하는 경우 대부분 필수 값이라 null값이 들어오게 되면 에러가 발생한다 이때 required를 false값(default가 true)으로 주게 되면 해결이 된다 더 나아가서는 default value를 정의하여 해당 값이 없을 때 default값을 줄 수 있다 (이렇게 되면 항상 값이 존재하니 required는 생략해도 무방) //예시 public void ..
- Total
- Today
- Yesterday
- ExceptionHandlerExceptionResolver
- Spring MVC
- Session
- 제이쿼리 위치탐색선택자
- OOP
- 제이쿼리 인접 관계 선택자
- maenco
- spring
- 제이쿼리 직접 선택자
- cookie
- Spring API Error
- jQuery 직접 선택자
- 제이쿼리 탐색선택자
- DefaultHandlerExceptionResolver
- @ResponseStatus
- DTO와 VO의 차이
- Cache
- uri
- 제이쿼리란
- application/x-www-form-urlencoded
- 캐시
- Spring TypeConverter
- 맨코
- http
- @ExceptionHandlere
- 쿠키
- 제이쿼리 기본 선택자
- ResponseStatusExeceptionResolver
- 세션
- Spring Container
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |