DI (Dependency Injection, 의존성 주입) DI(Dependency Injection, 의존성 주입)는 IoC(Inversion of Control, 제어의 역전)의 구현 방법 중 하나입니다. 즉, IoC가 객체의 생성과 생명주기 관리를 프레임워크가 담당하는 전반적인 개념이라면, DI는 그 개념을 실제로 구현하는 방식 중 하나입니다. DI의 주요 개념 의존성 객체지향 프로그래밍에서 한 클래스가 다른 클래스에 의존하게 되는 경우 예를 들어, 클래스 A가 클래스 B의 메소드를 사용한다면, 클래스 A는 클래스 B에 의존하게 됩니다. 주입: 의존성 주입이란, 객체가 자신이 의존하는 객체를 직접 생성하거나 찾는 대신에 외부 시스템(즉, 프레임워크 또는 IoC 컨테이너)에서 생성된 것을 제공(주입..
DEV/Java
Intro. 난, 손 발 달린 감자인가…? 🐥 카카오 테크 캠퍼스 - 2단계 4주차 과제 분석을 하고 과제를 수행하던 중, 컨트롤러 테스트에서 문제를 직면했다 "음흠, Product Controller에서 fakestore를 사용하니, MockBean을 만들어줘야지 그럼그럼"하면서 개발을 하고 있었는데 말이다, 분명히 데이터를 넣고, Request 내용을 출력했을 때 분명히 데이터가 출력이 되는데, 테스트 실행 결과에 response가 비어있다 기능 명세에 따르면 분명히, Request와 동일하게 데이터가 나와야 하는데 나오지 않는 것이다, 삽질 Get 요청에 Content 담아 전송 ResultActions result = mvc.perform( MockMvcRequestBuilders .get("/p..
Intro. 사건의 전말 🐥 카카오테크캠퍼스 - 2단계 3주차 과제 구현 피드백이 도착했다는 알림에 후다닥 달려갔다 3주차 과제는 Repository Test가 핵심이라, 관련 피드백이 달렸다 처음 멘토님의 피드백을 읽고, 잘이해가 되지 않았다 문제의 코드 나름 피드백은 반영하려 했지만, 멘토님이 원한 방향이 아닌거 같아 다시금 질문을 드렸다 결론 일반적으로 PK로 사용되는 Id는 자동 증가를 사용하는 경우가 있어, 테스트시에 변경 될 여지가 있다 핵심은 유니크하게 데이터를 구분하여, 변경의 위험을 탈출하라 전역 변수 테스트할때 아이디를 활용하여 조회하는 경우 ID는 자동증가를 사용하기 때문에 내가 원하는 아이디가 나오지 않아서 테스트가 실패할 수도 있습니다. 예를 들어 유저정보를 @BeforeEach ..
@Transactional 어노테이션은 Spring에서 데이터베이스 트랜잭션의 범위를 정의하기 위해 사용됩니다 이 어노테이션은 메서드(또는 클래스)를 트랜잭션 내에서 실행되도록 표시합니다. @Transactional 어노테이션은 클래스 수준, 메서드 수준 또는 둘 다에 적용할 수 있습니다. 클래스 수준에 적용하면 해당 클래스 내의 모든 메서드에 대한 기본 트랜잭션 동작이 설정됩니다. 트랜잭션 전파 트랜잭션 전파는 한 메서드에서 다른 메서드를 호출할 때 트랜잭션 동작이 어떻게 전파되는지를 정의합니다. 스프링은 @Transactional 어노테이션의 propagation 속성을 통해 다양한 전파 유형을 지원합니다. 일반적인 전파 유형은 다음과 같습니다: REQUIRED 메서드는 트랜잭션 내에서 실행되어야 합..
A - Atomicity Spring Boot에서, [[@Transactional]] 어노테이션을 사용하여 메서드의 원자성을 보장할 수 있습니다. 이 어노테이션은 메서드에서 발생하는 모든 데이터베이스 연산이 하나의 트랜잭션으로 처리되도록 합니다. 만약 메서드 내에서 어떤 예외가 발생하면, 해당 트랜잭션의 모든 연산은 롤백됩니다. @Service public class UserService { @Autowired private UserRepository userRepository; @Transactional public void updateUserEmail(Long id, String newEmail) { User user = userRepository.findById(id).orElseThrow(() -..
서비스와 리포지토리 계층 책임의 차이점 서비스 계층과 리포지토리 계층의 주요 차이점은 다음과 같은 책임입니다. 서비스 레이어 비즈니스 로직을 구현 리포지토리 레이어와 상호 작용하여 데이터를 검색 및 저장 트랜잭션을 관리 리포지토리 레이어 데이터 액세스 및 저장 엔터티에 대한 CRUD 작업을 수행 데이터베이스와 상호 작용 서비스 계층은 비즈니스 규칙 및 작업 실행에 중점을 두는 반면 리포지토리 계층은 데이터 지속성과 관련됩니다. 1 단계: 컨트롤러 계층에서 요청 받기 먼저 서비스 계층은 컨트롤러 계층에서 요청을 받습니다. 요청에는 컨트롤러가 클라이언트로부터 수신하고 검증한 데이터가 포함될 수 있습니다. @Service public class UserService { @Autowired private Use..
- Controller의 책임 : HTTP 요청 검증과 전처리 컨트롤러 계층은 웹 애플리케이션에서 들어오는 요청의 진입점이며 이러한 요청을 처리하는 특정 역할을 합니다. Service 계층과의 차이점 컨트롤러 레이어 HTTP 요청 및 응답을 처리하고, 요청을 검증하고, 비즈니스 로직을 서비스 레이어에 위임합니다. 서비스 계층 비즈니스 로직을 포함하고 데이터 검색 및 저장을 위해 저장소 계층과 상호 작용하며 트랜잭션을 관리할 수 있습니다. 컨트롤러 계층은 비즈니스 규칙이나 데이터 스토리지와 관련이 없는 반면 서비스 계층은 HTTP 프로토콜 세부 정보를 처리하지 않습니다 1단계: 요청 받기 컨트롤러 계층은 클라이언트로부터 들어오는 HTTP 요청을 받습니다. 이러한 요청을 적절한 처리기 메서드로 라우팅하는 일..
자바에서 특정한 예외 상황을 더 명확하게 표현하고자 할 때는 커스텀 예외 클래스를 정의할 수 있습니다. 커스텀 예외 클래스를 사용하면 예외가 발생한 원인이나 상황에 대한 자세한 정보를 담을 수 있습니다. Exception 400 유효성 검사 실패나 잘못된 요청을 의미합니다 @Getter public class Exception400 extends RuntimeException { public Exception400(String message) { super(message); } public ApiUtils.ApiResult body() { return ApiUtils.error(getMessage(), HttpStatus.BAD_REQUEST); } public HttpStatus status() { r..
HTTP 상태 코드는 HTTP 응답의 일부로, 서버가 클라이언트의 요청을 어떻게 처리했는지를 나타냅니다. 상태 코드는 클라이언트에게 요청의 성공, 실패 및 원인에 대한 정보를 제공합니다. 상태 코드를 Body에 담는 이유 상태 코드를 HTTP 응답의 본문(Body)에 포함시키는 이유는 두 가지 주요한 이유가 있습니다: 1. 상세한 정보 제공 상태 코드만으로는 에러의 세부 사항을 충분히 설명할 수 없습니다. 본문에 상태 코드와 함께 에러 메시지를 제공하면, 클라이언트는 에러의 원인을 더 정확하게 파악할 수 있습니다. 2. 응용 프로그램의 일관성 유지 본문에 상태 코드를 포함시키면, 응용 프로그램 내에서 에러 응답의 형식을 일관되게 유지할 수 있습니다. 보통 헤더에 상태 코드를 포함해서 반환을 하는데, 이 ..
- DTO에 @Pattern을 붙이면 된다 멘토님께서는 정규 표현식을 공부하는 것을 추천하지 않는다고 한다. ChatGPT에게 물어보면서 테스트를 진행하는걸 추천하신다 요청 DTO에 정규표현식 적용 DTO(Data Transfer Object)를 생성하고, @Pattern 어노테이션을 적용하면 됩니다. import javax.validation.constraints.Pattern; public class UserRequest { @Getter @Setter public static class JoinDTO { @NotEmpty @Pattern(regexp = "^[\\w._%+-]+@[\\w.-]+\\.[a-zA-Z]{2,6}$", message = "이메일 형식으로 작성해주세요") private Str..
