끄적끄적 개발

지난 글에서 SSE 란 무엇인지에 대해 알아보았다. 개념과 실전은 다르다고, 이번 글에서는 직접 스프링에서 SSE를 구현해보고 내가 겪은 트러블 슈팅과, 약간의 의문점?들을 해결해나간 과정을 정리해보려고 한다. 거두절미하고 시작해보자. SseEmitter를 이용한 SSE 구현스프링 4.2부터는 SSE 통신을 지원하는 SseEmitter API를 제공하여 보다 쉽게 SSE를 구현할 수 있다. 뒤에서 보겠지만 클라이언트 - 서버 간 SSE 연결 시 SseEmitter 객체를 하나 생성하고 이 객체를 통해 서버 → 클라이언트로 이벤트를 전송할 수 있다. 아래는 서버가 클라이언트에게 전송하는 메시지 내용인 Notification 엔티티로, 간단하게 id, message 필드 그리고 수신자를 의미하는 User 엔..

부모 엔티티 삭제 시 자식 엔티티를 어떻게 처리할지 따로 지정해주지 않으면, 다음과 같이 DB 상에서 FK 제약 조건을 위반했다는 오류를 뱉으면서 요청 처리에 실패하게 된다. 부모 엔티티를 삭제하는 경우 자식 엔티티를 어떻게 처리할지에 대해서는 구현하고자 하는 어플케이션의 비즈니스 로직에 따라 다를 것이다. 예를 들어 게시글을 삭제하는 경우 해당 글에 포함된 댓글 역시 모두 삭제해야 하는 반면, 어느 회사 내의 팀이 해체된다면 즉 팀이 삭제되는 경우에는 해당 팀에 속한 사원들의 정보는 삭제하지 않고 해당 사원의 소속팀 값을 NULL 또는 "무소속" 등과 같은 기본값으로 수정해주어야 한다. Spring Data JPA는 이렇게 부모 엔티티 삭제 시 자식 엔티티는 어떻게 처리할지에 대해 여러 옵션을 제공한다..

Facade 패턴 적용 이유 Service가 Controller의 DTO에 의존 개인 프로젝트를 진행하고 있던 중 고민인 부분이 생겼다. 바로 Controller - Service - Repository 계층에서 요청 또는 응답 DTO가 어디까지 진입 가능할지, 어디서부터 만들어져 나갈지에 대한 것이다. (참고로 여기서 말하는 DTO는 계층 간 DTO가 아닌 사용자 요청으로부터 오는 DTO 혹은 사용자에게 응답으로 전달되는 DTO를 말한다. 즉 Controller의 인자 혹은 반환값으로 전달되는 DTO) 기존에는 해당 블로그를 참고하여 DTO가 Service Layer까지는 들어오고 해당 계층에서 나갈 수 있도록, Entity ↔ DTO 간 변환은 별도의 Mapper 클래스가 수행하도록 구현하였다. 따라..

이전 글에서는 가장 기본적인 프론트 컨트롤러의 구조에 대해서 알아보고 이를 구현해보았다. 사실 글을 쓰면서도 이렇게 까지 기본적인? 내용에 대해 글을 쓰고 코드로 구현을 해봐야 할까 싶었지만, 사실 스프링에서 구현된 프론트 컨트롤러 패턴은 매우매우 복잡해서 공부한 뒤 일주일만 지나도 이에 대해 확실하게 기억하기가 쉽지 않다. 그러나 아주 기본적이면서도 간단한 4개의 객체로만 구성된 구조를 파악하고 기억하는 것은 매우 쉬운데 이를 통해 오랫동안 스프링의 구조를 잘 기억할 수 있기를 바라며 글을 작성해 보았다. 또한 프레임워크를 한번도 공부해본 적이 없는 분들에게도 도움이 되지 않을까 한다. 각설하고 이번 글에서는 지난번에 구현했던 프론트 컨트롤러 패턴을 조금더 향상된 구조로 리팩토링하려고 한다. 지난 구조..