본문 바로가기

Spring

 (183)
[Spring MVC] 요청 검증 - Bean Validation 이전 장(링크) 에서는 스프링의 메시지 기능을 사용하여 체계적인 오류 코드와 메시지 처리 방법에 대해서 알아보았다. 이번 장에서는 스프링의 Bean Validation을 사용한 검증 방법에 대해서 알아본다. 모든 코드는 깃 허브(링크) 에 올려두었다. Bean Validation 우리는 자바 코드를 작성하여 데이터의 유효성 검사를 진행하였다. 특정 필드의 값에 대한 검증 로직은 대부분 유사한 검증이기 때문에 간단한 애노테이션 작성을 통해서도 가능하다. 이렇게 검증 로직을 모든 프로젝트에 적용할 수 있도록 공통화하고 표준화한 것을 Bean Validation이라고 한다. Bean Validation은 특정 구현체가 아니라 Bean Validation 2.0(JSR-380)이라는 기술 표준이다. 검증 애노테..
[Spring MVC] 요청 검증 - 코드 & 메시지 이전 장(링크) 에서는 기본적인 방법으로 파라미터의 유효성을 검사하는 방법에 대해서 알아보았다. 이번 장에서는 스프링의 메시지 기능을 사용하여 체계적인 오류 코드와 메시지 처리 방법에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 메시지 사용 message.properties 파일과 errors.properties 파일을 추가하고 스프링 부트가 해당 메시지 파일을 인식할 수 있게 application.properties 파일을 수정한다. application.properties spring.messages.basename=messages,errorserrors.properties required.item.itemName=상품 이름은 필수입니다. range.item.price=가격은 {0} ..
[Spring MVC] 요청 검증 이번 장에서는 클라이언트가 전달한 파라미터의 유효성을 검사하는 방법에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. Validation(유효성 검사) 컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 그리고 정상 로직보다 이런 검증 로직을 잘 개발하는 것이 더 어려울 수 있다. 참고로 클라이언트에서 파라미터를 검증하는 것과 서버에서 파라미터를 검증하는 차이는 아래와 같다. 클라이언트 검증은 조작할 수 있으므로 보안에 취약하다. 예를 들어 API 요청에 필요한 정보를 직접 포스트 맨이나 curl로 요청하는 경우가 있다. 서버만에서만 검증하면, 즉각적인 고객 사용성이 부족해진다. 예를 들어 비밀번호 유효성의 경우 요청버튼을 클릭 하였을 때가 아니라 입력하는 즉시 화면에..
[Spring MVC] 메시지, 국제화 - 활용 이전 장(링크) 에서는 메시지, 국제화를 적용하고 테스트하는 방법에 대해서 알아보았다. 이번 장에서는 하드코딩 되어 있는 HTML파일을 메시지, 국제화를 적용하는 방법에 대해서 알아보도록 한다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃 허브(링크) 에 올려두었다. Legacy 예시에서는 상품 ID, 상품명, 가격, 수량에만 적용한다. 다른 곳에도 적용하는 방법이 궁금하다면 필자의 깃허브에 있는 mvc 리포지토리를 확인하도록 한다. 먼저 하드코딩되어 유지보수가 어려운 코드를 확인해본다. 상품 ID 상품명 가격 수량 properties 추가 메시지 국제화를 적용시키기 위해 /resources경로에 messages.properti..
[Spring MVC] 메시지, 국제화 - 적용 이번 장에서는 메시지, 국제화를 적용하고 테스트하는 방법에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 내용은 강의나 공식문서에서 확인한다. 모든 코드는 깃 허브(링크) 에 올려두었다. 메시지 기능의 필요성 아래와 같은 방식으로 상품명, 가격이라는 문구가 하드코딩 되어있다고 가정해본다. 상품명 가격 상품명이라는 문구를 상품이름이라는 문구로 변경해달라는 요청이 들어오면 우리는 상품명이라는 모든 문구를 찾아서 변경해주어야 한다. 만약 우리가 HTML코드에 상품명 문구를 직접 입력하여 사용한 것이 아니라 한 곳에서 관리하고 관리되는 메시지를 가져다 쓴 것이라면 우리는 관리되는 한 곳만 수정하면 된다. 이렇게 메시지가 한 곳에서 관리되도록 하는 기능을 메시지 기능이라고 ..
[Spring Cloud] Microservice Pattern 이번 장에서는 Microservice의 패턴에 대해서 알아본다. Event Sourcing Monolithic 방식에서는 단일 데이터베이스를 사용한다. 단일 데이터베이스를 사용하고 있기 때문에 Atomicity, Consistency, Isolation, Durable라는 특징을 완벽하게 지원한다. Microservice는 서비스마다 독립적인 프레임워크, 언어, 데이터베이스등을 선택할 수 있다.(Polyglot) 다른 서비스들이 제공하는 정보를 위해서는 API를 통해서 통신해야 한다. Microservice에서는 Monolithic방식에서 지원하는 ACID라는 속성을 완벽하게 지원하기는 쉽지 않으며 다른 방식으로 우회하여 비슷하게 동작하도록 유도한다. Commit Transaction 예를 들어 Comm..
[Spring Cloud] Microservice Architecture 이전 장(링크) 에서는 Software Architecture에 대해서 알아보았다. 이번 장에서는 Microservice Architecture에 대해서 알아보도록 한다. Monolith vs Microservice Monolith방식은 애플리케이션을 구성하기 위한 모든 구성요소를 하나의 서비스로 개발하는 방법이다. 구성요소에는 DB 접근기술, 비지니스 로직, 프론트엔드등이 포함된다. 이러한 서비스들이 서로 의존성을 가지고 패키징되고 운영서버에 배포되는 방식을 의미한다. Microservice방식은 애플리케이션을 구성하는 구성요소를 분리하여 개발하고 운영하는 방식을 의미한다. 하나의 큰 형태로 개발되는 Monolithic 방식에 비해 유지보수나 변경사항을 적용하는데 유리하다. 어떠한 비즈니스 로직이 수정..
[Spring Cloud] Software Architecture 이번 장에서는 마이크로서비스 아키텍쳐를 알아보기 위해 IT System이 어떻게 발전해왔는지 알아보도록 한다. 소프트웨어 아키텍쳐 1960 ~ 1980s(Fragile, Cowboys): 소프트웨어보다 하드웨어 사양에 맞춰서 개발하던 시절이다. 하드웨어나 시스템이 고가였기 때문이다. 이 때는 Fragile이라는 "깨지기 쉬운"이라는 뜻을 가지고 있다. 1990 ~ 2000s(Robust, Distributed): 안정화되고 분산화된 시스템 덕분에 안정성있고 성능이 높은 서비스를 유지할 수 있게 되었다. 2010s ~ (Resilient/Anti-Fragile, Cloud Native): 안정화되고 Fragile과 반대되는 Anti-Fragile 성향과 Cloud Native라는 키워드가 등장한다. 지속적..

티스토리툴바