본문 바로가기

Spring36

Spring API 예외 처리 시스템 정리 목표: 깔끔하고 일관된 예외 처리 시스템 구축핵심 아이디어: ErrorCode Enum + BusinessException + ApiResponse + @ControllerAdvice 조합1단계: ErrorCode Enum 정의public enum ErrorCode { // 사용자 관련 (4xx) USER_NOT_FOUND(404, "U001", "사용자를 찾을 수 없습니다"), USER_ALREADY_EXISTS(409, "U002", "이미 존재하는 사용자입니다"), USER_UNAUTHORIZED(401, "U003", "권한이 없습니다"), // 상품 관련 (4xx) PRODUCT_NOT_FOUND(404, "P001", "상품을 찾을 수 없습니다"), .. 2025. 6. 5.
[트러블슈팅] JPA Cascade와 트랜잭션 전파 - 편의성 vs 안전성 "JPA 고급 기능, 정말 써야 할까?" 시리즈 4편 (완결편)들어가며시리즈의 마지막 편입니다. 1편에서 연관관계 매핑의 복잡성을, 2편에서 상속관계 매핑의 실무 한계를, 3편에서 지연로딩의 함정과 해결책을 다뤘다면, 이번에는 영속성 전이(Cascade)와 트랜잭션 전파에 대해 이야기해보겠습니다. 이 두 기능의 공통점은 "편의성"입니다. 코드를 간단하게 만들어주는 매력적인 기능들이죠. 하지만 편의성 뒤에 숨겨진 "위험성"도 함께 알아야 합니다."편리하다고 해서 항상 좋은 것은 아니다" - 이것이 이번 편의 핵심 메시지입니다.영속성 전이(Cascade): 편리하지만 위험한 마법게시판으로 이해하는 Cascade블로그 게시판을 예로 들어보겠습니다:@Entitypublic class Post { @Id @.. 2025. 6. 5.
[트러블슈팅] JPA 지연로딩과 Proxy - LazyInitializationException 해결하기 "JPA 고급 기능, 정말 써야 할까?" 시리즈 3편들어가며1편에서 연관관계 매핑의 복잡성을, 2편에서 상속관계 매핑의 실무 활용을 다뤘다면, 이번에는 지연로딩과 Proxy에 대해 이야기해보겠습니다.처음 Proxy 개념을 접했을 때 정말 헷갈렸습니다. "가짜 객체가 뭐지?" "언제 실제 데이터를 가져오는 거지?" 이런 의문들이 계속 들더군요. 하지만 "왜 Proxy가 필요한가?"부터 이해하니 모든 게 명확해졌습니다.문제 상황: 성능과 편의성의 딜레마배달앱으로 이해하는 즉시로딩 vs 지연로딩온라인 배달앱을 생각해보겠습니다:@Entitypublic class Order { @Id @GeneratedValue private Long id; private int amount; @Ma.. 2025. 6. 5.
[트러블슈팅] JPA 상속관계 매핑 3가지 전략 - 실무에서는 언제 쓸까? "JPA 고급 기능, 정말 써야 할까?" 시리즈 2편들어가며1편에서 연관관계 매핑의 복잡성에 대해 이야기했다면, 이번에는 상속관계 매핑을 다뤄보려 합니다.처음 상속관계 매핑 강의를 들을 때는 정말 이해가 안 됐습니다. @Inheritance, @DiscriminatorColumn, InheritanceType.JOINED... 무슨 말을 하고 있는지 전혀 모르겠더군요.하지만 "왜 이게 필요한가?"부터 생각해보니 개념이 명확해졌습니다. 그리고 실무에서는 언제 써야 하는지도 보이기 시작했습니다.문제 상황: 공통 속성과 개별 속성쇼핑몰 상품 관리의 고민온라인 쇼핑몰에서 다양한 상품을 관리한다고 생각해보겠습니다:// 책- 이름, 가격, 저자, ISBN// 영화 - 이름, 가격, 감독, 배우// 앨범- 이름, .. 2025. 6. 4.
[트러블슈팅] JPA 연관관계 매핑 vs Repository 패턴 - 어떤 게 더 안전할까? "JPA 고급 기능, 정말 써야 할까?" 시리즈 1편 들어가며스프링 부트 강의 2주차를 들으며 JPA 연관관계 매핑을 배웠습니다. @OneToMany, @ManyToOne, @OneToOne, @ManyToMany... 다양한 어노테이션들과 함께 객체 간의 관계를 매핑하는 방법을 익혔습니다.하지만 학습하면서 계속 드는 의문이 있었습니다."이렇게 서로 참조하면 의존성이 생기는 거 아닌가?"실무에서도 정말 이런 식으로 연관관계를 사용할까? Repository 패턴으로 필요시 조회하는 게 더 안전하지 않을까? 이런 고민을 하게 되었습니다.연관관계 매핑의 기본 개념전형적인 연관관계 매핑@Entitypublic class User { @Id @GeneratedValue private Long id; .. 2025. 6. 4.
Spring 데이터 변환 컴포넌트들 오늘 배운 내용스프링 숙련 단계 강의에서 HttpMessageConverter, Converter, ConversionService, Formatter에 대해 학습했습니다.핵심 개념 정리HttpMessageConverterHTTP 요청/응답 본문과 객체 간의 변환을 담당JSON ↔ Java 객체 변환이 대표적인 예Spring MVC 플로우에서 양방향으로 작동:요청 시: ArgumentResolver에서 @RequestBody 처리응답 시: ReturnValueHandler에서 @ResponseBody 처리 Converter vs Formatter처음엔 둘이 비슷해 보였지만 차이가 있었습니다: Converter타입 간 일반적인 변환 (A → B)양방향 처리시 별도 Converter 필요주로 내부 로직에서 .. 2025. 6. 4.
Spring Layered Architecture 기존에 사용하던 MVC 패턴에는 문제점이 있는데, Controller는 역할이 너무 많다는 문제점이다.요청에 대한 처리예외처리View Template 응답 or Data 응답비지니스 로직 처리DB 상호작용코드 재사용성을 위해 여러 Layer로 나누어 역할을 분담해주는 구조가 Layered Architecture 이다.Presentation Layer클라이언트의 요청을 받는 역할을 수행한다.요청에 대한 처리를 Service Layer에 전달한다.Service에서 처리 완료된 결과를 클라이언트에 응답한다.사용하는 Annotation : @Controller, @RestController Business Layer(Service Layer)사용자의 요청 사항을 처리한다.DB와 상호작용이 필요한 경우, Repo.. 2025. 5. 9.
Spring @PathVariable vs @RequestBody @GetMapping("/{id}") public ResponseEntity findMemoById(@PathVariable Long id) { return new ResponseEntity(memoService.findMemoById(id), HttpStatus.OK); } 여기서는 왜 @RequestBody를 안해줬을까? 이 이유는 HTTP GET 요청의 특성과 관련이 있다.1. GET 요청의 특징GET 방식은 리소스를 "조회"할 때 사용GET 요청은 **request body(본문 데이터)**를 사용하지 않고,대신 요청 URL의 경로 또는 쿼리 파라미터에 데이터를 담아서 서버에 전달 GET /memos/1 여기서 /1이 PathVariable에 해당하며, 이 id 값이 Co.. 2025. 5. 9.
Spring @RestController & ResponseEntity<T>에 대해 @RestController만 사용해도 DELETE와 PUT 요청을 처리할 수 있다.하지만, 응답 상태 코드나 헤더를 제어하고 싶을 때는 ResponseEntity를 사용하는 것이 더 유리하다.ResponseEntity는 특정 타입 T의 데이터를 HTTP 응답으로 감싸서 반환하기 위한 객체@RestController는 응답 바디를 자동으로 직렬화하여 반환해 주기 때문에, 간단한 응답을 처리할 때는 매우 유용하다.ResponseEntity는 응답 상태 코드와 헤더 등을 세밀하게 제어할 수 있기 때문에, 복잡한 응답 처리가 필요한 경우에 사용된다.@RestController와 응답 @RestController는 @Controller와 @ResponseBody를 결합한 어노테이션. 즉, 메서드의 반환값을 HT.. 2025. 5. 8.
Spring DTO에 대해 DTO는 Data Transfer Object의 줄임말로,"데이터 전송을 위한 객체", 말 그대로 데이터만 담아서 전달하는 용도의 객체이다. DTO는 데이터 전달용 전용 클래스로,비즈니스 로직 없이, 필요한 데이터만 담아서 계층 간 또는 클라이언트와 서버 간 전송할 때 사용한다. Spring이 아니더라도 객체지향 프로그래밍(OOP)에서 데이터를 나누어 클래스로 표현하고 getter로 데이터를 꺼내 쓰는 건 매우 일반적인 패턴이다.DTO도 그런 객체 중 하나의 역할을 수행하는 특화된 형태라고 보면 된다. 둘의 차이점 중에는 일반 클래스에는 비즈니스 로직을 가질 수도 있지만, DTO는 로직을 갖지 않고 getter/setter 정도만 존재한다.항목설명목적계층 간 데이터 전달 (Controller ↔ Ser.. 2025. 5. 8.
Spring MVC 구조 MVC란? 구성요소역할설명Model데이터, 비즈니스 로직DB에서 가져온 데이터를 보관하고 처리하는 역할. 예: DB 모델, DTO, 서비스 로직 등View화면(UI)사용자에게 보여지는 부분. 예: HTML, JSP, Thymeleaf 템플릿Controller흐름 제어사용자의 요청을 받고, Model과 View 사이를 연결 ( @Controller, @RestController 클래스) Spring MVC 흐름 요약사용자가 요청 (ex. /user)DispatcherServlet이 요청을 받는다. (웹 애플리케이션에서 들어오는 모든 HTTP 요청을 가장 먼저 받아서, 적절한 Controller로 전달하는 중앙 처리자 역할)적절한 Controller에게 전달Controller는 필요한 Model 데이터를 준.. 2025. 5. 8.
Spring 요청 & 응답 데이터 Client에서 Server로 Data를 전달하는 방법은 Query Parameter, HTTP Form Data, HTTP Request Body 크게 세가지가 있다. 1. GET + Query Parameter(=Query String) : URL의 쿼리 파라미터를 사용하여 데이터 전달하는 방법 / 주로 GET 요청에서 사용HttpServletResponse를 사용해서 응답값을 직접 다룰 수 있다.받는 방식 : RequestParam 2. POST + HTML Form(Content-Type 기본값: application/x-www-form-urlencoded) : HTTP Request Body에 쿼리 파라미터 형태로 전달하는 방법 / HTML 을 사용할 때 자동으로 생긴다.데이터는 key=v.. 2025. 5. 8.

티스토리툴바