스프링 스터디

Spring에서 @RequestBody로 DTO를 받을 때, 필드가 하나인 DTO는 때때로 기본 생성자 없이는 역직렬화 오류가 발생합니다. 음.. 코드 상에서 실행 시, 오류 안나는데요?당장 IntelliJ에서 오류가 나지는 않지만 메인 코드를 실행했을 때, titl

Spring Data JPA에서는 트랜잭션 내에서 영속성 컨텍스트에 의해 관리되고 있는 엔티티의 상태가 변경되면,트랜잭션이 종료되기 전 자동으로 변경 내용을 감지하여 DB에 반영해 줍니다.즉, 별도로 save()를 호출하지 않아도 됩니다.Spring Data JPA에서

🧠 검증 로직은 어디에 두어야 할까? > 검증 로직은 Service 계층 내부에 위치시키되, > 상태와 의존성이 없는 공통 검증은 유틸 클래스로 분리하여 > 재사용성과 테스트 용이성을 확보하는 것이 가장 이상적인 구조입니다. ✅ 그렇다면.. 검증 로직은 비즈니스

Optional<Post> findTopByOrderByCreatedAtDesc()→ 조회 결과가 없을 수도 있기 때문입니다.findTopByOrderByCreatedAtDesc()는 가장 최근에 작성된 게시글 1개를 조회합니다.그런데 게시글이 하나도 없다면?→

IoC는 객체의 생성, 초기화, 의존 관계 설정 등 제어 흐름을 개발자가 아닌 프레임워크(예: Spring) 가 담당하게 만드는 디자인 원칙입니다.우리가 라면을 끓일 때 직접 물을 끓이고, 면을 넣고, 스프도 직접 넣고 타이머까지 맞춰야 합니다.이건 모든 과정을 내가

RESTful이라는 단어는 이제 너무 흔하게 들리지만,저는 그 안에서 실제 설계에 도움이 되는 기준이 무엇인지 항상 고민해왔습니다.제가 중요하게 생각하는 RESTful의 핵심은 단 하나입니다."URI와 메서드만 보고도 이 API가 무슨 일을 하는지 직관적으로 파악할 수

Spring에서 의존성 주입은 객체 간 결합도를 낮추고 테스트와 유지보수를 쉽게 하기 위한 핵심 원칙입니다.대표적으로 생성자 주입, 필드 주입, 세터 주입이 있으며, 각 방식은 코드 구조, 장단점이 분명히 다릅니다.final 필드 사용 가능 → 불변성 보장컴파일 타임에

RESTful API를 설계하다 보면, 누구나 한 번쯤은 헷갈려보았을 POST vs PUT vs GET의 구분.특히 "검색(Search)" 기능을 설계할 때 어떤 메서드를 써야 할지 고민한 적이 있습니다.지금부터 고민한 내용을 적어보겠습니다!항상 새로운 리소스가 생성

JPA를 사용해 CRUD 기반의 API를 개발하던 중, Read 작업(R) 에서 성능 병목이 발생하는 것을 경험했습니다.특히, 복잡한 조회 로직을 JPA로 처리할 때, 비효율적인 쿼리 생성, N+1 문제, 성능 이슈가 자주 발생했습니다.이러한 문제를 해결하기 위한 방법

Spring에서 Controller 단에서 아래처럼 코드를 자주 보게 됩니다.여기서 자연스럽게 드는 의문:"왜 Controller가 Service를 갖고 있어야 하지?Controller는 그냥 요청만 받고 넘기는 건데, 이게 꼭 필요할까?"저도 처음에는 "Control