개발놀이터

이 포스팅은 인프런 김영한님의 스프링 핵심 원리 기본편을 보고 각색한 포스팅입니다. 자세한 내용은 강의를 확인해주세요 코드에 들어가기 전 이 코드의 배경이 되는 스토리가 있는데 사장님이 할인 정책을 구상하는데 VIP에게 정액할인제를 할지 정률할인제를 할지 고민하는 상황이다. 사장님이 할인 정책에 대해서는 중요한 사항이므로 런칭하기 바로 직전까지 생각하다 적용할 예정이다. 기획자는 일단 둘 다 만들어 놓고 우선 정액할인제를 적용한 상태로 개발에 착수하라는 지령이 떨어졌다. 우리의 개발자는 언제 할인 정책이 바뀔지 모르는 상황에서 개발에 착수해야 하며 런칭 바로 직전에 할인정책이 바뀔수도 있는 상황이다. Member.java public class Member { private Long id; private..

*객체지향 설계 SOLID 1. SRP (Single Responsibility Principle) : 단일 책임 원칙 -한 클래스는 하나의 책임만 가져야 한다. -하지만 하나의 책임이라는 것은 모호하다. --클 수도 있고, 작을 수도 있다. --문맥과 상황에 따라 다르다. -중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 2. OCP (Open / Closed Principle) : 개방-폐쇄 원칙 -소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다. -이런 거짓말 같은 말이? 확장을 하려면 당연히 기존 코드를 변경해야 하는것이 아닌가? -다형성을 활용해보면 된다. -인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현한다. ..

타임리프를 사용하면서 동적으로 클래스를 추가해주고싶은 경우가 있을 것이다. 예를 들어 값이 1이면 클래스를 추가하고 2면 클래스를 추가하고 이런식으로 말이다. 그럴 때 타임리프에선 classappend라는 기능을 제공한다. 공지사항 위의 예제는 notice의 값이 1이면 notice라는 클래스를 추가하는 문법이다. 나의 경우 공지사항을 상단에 노출시키고 노출시킨 공지사항만 색을 칠해주고 싶었다. 이와 같은 문법으로 th:errorclass 라는 문법도 존재한다. errorclass 는 BindingResult 값으로 에러가 넘어오면 클래스를 추가해주는 문법이다. 자세한 내용은 아래의 게시글을 참고하자 https://coding-review.tistory.com/72 스프링 Validation 본 포스트는..

구글의 SMTP를 이용하던 중 생긴 오류 구글링을 해보니 사용중인 구글 계정에 대해서 보안 수준이 낮은 앱 엑세스가 허용되지 않아서 메일을 보내는데 실패한 것으로 판단, 해결방법으로는 계정의 보안 수준이 낮은 앱의 엑세스 탭으로 이동하여 허용해주면 된다. 이렇게 하면 해결 되지만.. 보안이 취약해질 수 있다는 말이 좀 꺼림칙해서 다른 해결 방법을 찾아보기로 마음먹었다. 로그에 찍힌 주소로 들어가보면 이런 내용이 나온다. https://support.google.com/mail/?p=BadCredentials 다른 이메일 플랫폼을 통해 Gmail 확인하기 - Gmail 고객센터 도움이 되었나요? 어떻게 하면 개선할 수 있을까요? 예아니요 support.google.com 2단계 인증이 필요한 SMTP는 앱..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요. *스프링 타입 컨버터 문자를 숫자로 변환하거나, 반대로 숫자를 문자로 변환해야 하는 것 처럼 애플리케이션을 개발하다 보면 타입을 변환해야 하는 경우가 상당히 많다. 스프링을 사용하지 않는다면 보통의 경우 WrapperClass의 valueOf (String.valueOf, Integer.valueOf 등등) 메소드를 사용하거나 WrapperClass의 pasrseSomething (parseInt, parseDouble 등등) 메소드를 사용하는 것이 대부분일 것이다. 하지만 이렇게 일일이 타입을 변환해주는 것은 매우 번거로운 일이다. 혹은 단순히 타입 변환이..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요. *API 예외처리 HTML 페이지의 경우 4xx, 5xx처럼 오류 페이지만 있으면 대부분의 문제를 해결할 수 있었다. 그런데 API의 경우에는 생각할 내용이 더 많다. 오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고 json으로 데이터를 내려줘야 한다. 지금부터 API의 경우 어떻게 에외 처리를 하면 좋은지 알아보자. APi도 오류페이지에서 설명했던 것처럼 처음으로 돌아가서 서블릿 오류 페이지로 방식을 사용해보자 @Component public class WebServerCustomizer..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요. *예외처리, 오류페이지 고객이 웹페이지를 이용함에 있어서 예외가 발생하거나 오류가 발생할 때를 대비해 오류페이지를 커스텀하여 만들면 좋은데 스프링부트가 제공하는 기본 오류페이지는 디자인적으로나 가독성면에서 좋지못하다. 그렇기 때문에 개발자는 고객을 위한 오류페이지를 따로 만들어야 한다. 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, 어디선가 try-catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그런데 만약 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요 *필터 로그인을 구현하는 경우 로그인을 하지 않으면 접근할 수 없는 페이지가 있을 것이다. 예를 들어 상품수정이나 상품등록같은 경우가 그런 경우일 것이다. 로그인을 하지 않은 사람을 거르는 로직을 컨트롤러에서 일일이 구현하려면 엄청난 하드코딩이 아닐 수 없다. 이를 해결하기 위해 서블릿에서는 필터, 스프링에서는 인터셉터를 제공한다. 필터는 애플리케이션 여러 로직에서 공통으로 관심이 있는 것을 공통 관심사라고 하는데 이런 공통 관심사를 처리하기 위해 존재한다. *서블릿 필터 소개 필터의 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 필터를..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요 *Bean Validation 검증 기능을 전 시간 처럼 매번 코드로 작성하는 것은 상당히 번거롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값이 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다. Bean Validation 시작하기 1. 의존관계 추가 build.gradle에 implementation 'org.springframework.boot:spring-boot-starter-validation' 를 추가한다. 2. @NotNull, @NotBlank, @NotEmpty등 어노테이션을 필드에 추가해준다. Bean Validat..

본 포스트는 김영한님의 인프런강의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 보고 정리한 포스트입니다. 자세한 내용은 강의를 참고해주세요 *검증 사용자가 상품 등록 폼에서 정상 범위의 데이터를 입력하면, 서버에서는 검증 로직이 통과하고, 상품을 저장하고, 상품 상세 화면으로 redirect한다. 고객이 상품 등록 폼에서 상품명을 입력하지 않거나, 가격, 수량 등이 너무 작거나 커서 검증 범위를 넘어서면, 서버 검증 로직이 실패해야 한다. 이렇게 검증에 실패한 경우 고객에게 다시 상품 등록 폼을 보여주고 어떤 겂을 잘못 입력했는지 친절하게 알려줘야한다. 스프링이 제공하는 검증 오류 처리 방법으로 BindingResult가 있다. 검증오류를 담아두는 곳이라고 생각하면 편하다. 앞으로 이 Bindin..