서비스와 리포지토리 계층 책임의 차이점 서비스 계층과 리포지토리 계층의 주요 차이점은 다음과 같은 책임입니다. 서비스 레이어 비즈니스 로직을 구현 리포지토리 레이어와 상호 작용하여 데이터를 검색 및 저장 트랜잭션을 관리 리포지토리 레이어 데이터 액세스 및 저장 엔터티에 대한 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..
DTO(Data Transfer Object)는 화면 과의 통신시 인터페이스와 비즈니스 로직 간의 데이터 전달을 담당하는 객체입니다 DTO 유효성 검사는 다음과 같은 목적을 가지고 수행 됩니다 1. 데이터의 유효성 확인 DTO 객체의 데이터 필드에 입력 된 값이 올바른 형식, 범위, 제약 조건을 충족하는지 확인합니다 숫자 필드에 숫자가 입력 되고, 문자열 필드에는 문자열이 입력 되어야 합니다 2. 비즈니스 규칙 준수 확인 DTO 객체가 비즈니스 규칙을 준수하는지 검사합니다. 주문을 나타내는 DTO에서 수량 필드는 음수가 될 수 없고, 가격 필드는 0 이상이어야 한다는 비즈니스 규칙이 있다면 검증 해야 합니다 3. 보안 검사 DTO 객체의 데이터가 보안 요구사항을 충족하는지 확인합니다 사용자의 비밀번호를 ..
측정 지표 레퍼지터리 단위 테스트 구현 테스트 메서드의 격리성이 보장 되었는가 테스트 코드 쿼리 관련 메서드가 너무 많은 Select를 유발하지 않는가 과제 목적 핵심은 내가 JPA 테스트를 통해 원하는 데이터를 얻어낼 수 있는가!! 그 데이터를 얻기 위해 너무 많은 select가 유발되지 않았는가? 테스트를 통해 JPA를 좀 더 잘 이해하는 것이다. Product 전체 상품 목록 조회 @Test public void product_findAll_test() throws JsonProcessingException { // given int page = 0; int size = 9; // when PageRequest pageRequest = PageRequest.of(page, size); Page pr..
🐥 카카오테크캠퍼스 - 2단계 3주차 - 과제 - 레포지토리 단위테스트 1. 레포지토리 단위테스트를 구현하여 소스코드를 제출하시오. 2. 쿼리를 테스트하면서 가장 좋은 쿼리를 작성해보시오. 핵심 지표 레포지토리 단위테스트가 구현되었는가? 테스트 메서드끼리 유기적으로 연결되지 않았는가? (테스트는 격리성이 필요하다) Persistene Context를 clear하여서 테스트가 구현되었는가 (더미데이터를 JPA를 이용해서 insert 할 예정인데, 레포지토리 테스트시에 영속화된 데이터 때문에 쿼리를 제대로 보지 못할 수 있기 때문에) 테스트 코드의 쿼리 관련된 메서드가 너무 많은 select를 유발하지 않는지? (적절한 한방쿼리, 효율적인 in query, N+1 문제 등이 해결된 쿼리) 🥔 내가 잘 모르는..
@Component - Spring에서 해당 클래스의 인스턴스를 싱글톤 생성 - Spring Context 내에서 전역적으로 사용가능하게 한다 @Component 어노테이션은 Spring에서 해당 클래스의 인스턴스가 필요할 때 Spring이 직접 관리하도록 해줍니다 이렇게 하면 Spring IoC Container는 이 클래스의 라이프사이클을 관리하게 됩니다. 다시 말해, 이 클래스의 인스턴스를 언제 생성하고, 언제 소멸시킬지 등을 결정하게 됩니다. 또한, 이 클래스를 필요로 하는 다른 클래스에게 자동으로 제공할 수 있게 됩니다. 이것은 모듈 간의 의존성 관리(DI (Dependency Injection))를 더욱 편리하게 만들어줍니다. 필요한 객체를 직접 생성하거나 찾는 대신, 필요한 곳에 적절하게 주..
Mock API 작성하는 팁 🐥 카카오테크캠퍼스 - 2단계 2주차 과제를 수행 할 때, 하나하나 데이터를 입력해야 하는 불편함이 있었는데 오늘 강사님이 보여주신 코드를 보니까 깔끔해서 들고 왔다 @GetMapping("/products") public ResponseEntity findAll(@RequestParam(defaultValue = "0") int page) { List responseDTO = new ArrayList(); // 상품 하나씩 집어넣기 responseDTO.add(new ProductRespFindAllDTO( 1, "기본에 슬라이딩 지퍼백 크리스마스/플라워에디션 에디션 외 주방용품 특가전", "", "/images/1.jpg", 1000 )); responseDTO.add(n..
