Spring
-
Spring 개방 폐쇄의 원칙을 반영한 코드 리팩토링Back-end/TIL 2022. 4. 25. 09:26
📌 상황 팀장님께서 리팩토링한 코드를 보고 인터페이스 구현체를 명시해주는 것에 대해 고민하며 ‘Spring의 개방 폐쇄 원칙’ 개념에 대해 직접적인 이해를 하게 되었다. 현재 회사 코드는 위와 같은 구조를 가지고 있고, 지금은 SmsExternalService 인터페이스의 구현체가 SmsNaverService 뿐이지만, 만약 다른 구현체가 생긴다면, SpringBoot가 어떤 구현체를 사용해야할 지 몰라 에러가 발생할 것이다. 따라서 이러한 부분에 대한 리팩토링이 추가로 필요하다고 생각했다. 📌 개선 @RestController public class UserV2Controller { private SmsExternalService smsExternalService; @PostMapping(..) pub..
-
[SpringBoot] 서버에서 사용자 입력 값과 Request Body를 Validation하는 2가지 방법Back-end/TIL 2022. 4. 4. 15:45
📌 Validation이 필요한 이유 의도적으로 이상한 값으로 서버에 요청을 보낼 수 있기 때문에 프론트와 서버에서 둘다 해줘야 한다. 회사 코드를 보니 이메일이나 전화번호 입력 값에 대한 형식을 모두 서버에서도 체크해주었다. (기존에 사이드 프로젝트 할 때는 '입력값은 프론트에서 유효성 검사 해주니까 괜찮겠지' 하고 넘어갔었는데 반성하게 되었다. 다음 사이드 프로젝트에서는 입력값에 대한 서버 유효성 검사도 추가해야겠다) 그렇다면, 어차피 서버에서도 유효성 검사를 해주는데 프론트에서도 하는 이유는? - 서버 부하를 줄여주고, 사용자의 편의성을 위해서이다. - 서버에서의 유효성 검사는 프론트에서의 유효성 검사보다는 느릴 수 밖에 없다. 📌 준비 의존성 추가 dependencies { implementati..
-
[SpringBoot] JPA를 통해 엔티티 반환시 DtoVo 사용하기Back-end/TIL 2022. 3. 16. 09:28
📌 상황 Spring Data JPA를 통해 엔티티 조회시 기존에는 아래와 같이 코드를 작성하였다. //기존 코드 Page findByMenuKorNameContains(String menuKorName, Pageable pageable); Page findByMenuEngNameIgnoreCaseContains(String menuEngName, Pageable pageable); 위의 코드가 틀린 것은 아니지만, 몇가지 문제점이 존재한다. 1. 기존의 방식은 엔티티 자체가 반환되기 때문에 만약 조회시 특정 필드 값만 필요하다면, 불필요한 필드 값이 모두 반환되는 상황이다. 2. 불필요한 필드가 많거나 해당 필드의 타입이 text와 같이 사이즈가 크다면, 성능 이슈가 발생할 수 있다. 즉, 기존의 방식..