이모저모

도윤·2024년 4월 4일

빌더 패턴의 사용이유

기본적으로 생성자를 사용하여 객체를 초기화할때 매개변수의 순서와 타입을 정확하게 기억해야 하고, 모든 매개변수를 순서대로 전달해야 한다. 그러나 빌더 패턴을 사용하면 각 매개변수의 의미를 명시적으로 지정할 수 있으며, 선택적 매개변수를 더 쉽게 처리할 수 있다.
또한 빌더 패턴은 가독성을 높일 뿐만 아니라 유지보수성도 향상시킨다. 코드에서 객체 초기화 부분이 더 명확하게 드러나며, 새로운 매개변수가 추가되더라도 기존 코드에 영향을 덜 준다.
결론적으로 빌더패턴의 사용으로 객체를 생성하는 것은 주로 가독성과 확장성을 개선하기 위한 목적으로 선택

toEntity

DTO를 실제 도메인 객체로 변환해주는 역할. 보통 웹 어플리케이션에서 클라이언트로부터 데이터를 받아 처리할 떄, DTO 를 사용하여 데이터를 전달하고 , 이를 도메인 객체로 변환하여 비즈니스 로직을 처리합니다.
DTO와 도메인 객체의 분리: DTO는 주로 외부 시스템과의 통신이나 데이터 전송을 위해 사용됩니다. 이런 목적을 위해 DTO를 사용하면 도메인 객체와 외부 시스템 간의 의존성을 줄일 수 있습니다. toEntity() 메서드를 통해 DTO에서 도메인 객체로의 변환을 명확하게 할 수 있습니다.
데이터의 유효성 검사: DTO는 외부로부터 데이터를 받아오는 역할을 하기 때문에, 보통 데이터의 유효성 검사를 수행합니다. 따라서 toEntity() 메서드 내에서 DTO의 데이터를 사용하여 필요한 유효성 검사를 수행할 수 있습니다. 이후에 데이터가 유효하다고 판단되면 도메인 객체를 생성하고 반환합니다
객체 생성의 추상화: toEntity() 메서드를 통해 도메인 객체를 생성하는 부분을 캡슐화하여, DTO의 내부 구현에 대한 변경이 생기더라도 이를 외부에 공개하지 않고 관리할 수 있습니다. 이는 코드의 유연성과 유지보수성을 높여줍니다.

RequiredArgsConstructor

lombok 에서 제공하는 어노테이션 중 하나. 클래스의 필드를 기반으로 생성자를 자동으로 생성해주는 역할.
보통 @AllArgsConstructor를 사용하여 모든 필드를 갖는 생성자를 만들거나, @NoArgsConstructor를 사용하여 파라미터가 없는 기본 생성자를 만들 수 있습니다. 그러나 때로는 클래스에 필드가 추가될 때마다 생성자를 수동으로 추가하는 번거로움이 발생할 수 있습니다. 이런 경우 @RequiredArgsConstructor를 사용하면, 클래스에 선언된 모든 필드를 갖는 생성자를 자동으로 생성해줍니다. 단, final로 선언된 필드에 대해서만 생성자가 만들어집니다.
따라서 @RequiredArgsConstructor를 사용하면 코드를 더 간결하게 유지할 수 있고, 새로운 필드를 추가할 때 생성자를 수동으로 추가하는 수고를 덜 수 있습니다.

@RequestBody

Spring MVC 에서 사용되는 어노테이션 중 하나로, HTTP 요청의 본문(body) 에 있는 데이터를 해당 메서드의 매개변수로 매핑하는 역할
일반적으로 클라이언트가 POST나 PUT 요청을 보낼 때, 요청 본문에 JSON 또는 다른 형식의 데이터를 담아서 보내는 경우가 많습니다. 이런 경우에 @RequestBody 애노테이션을 사용하여 HTTP 요청 본문에 있는 데이터를 자바 객체로 변환하여 컨트롤러의 메서드에 매핑할 수 있습니다.
따라서 @RequestBody 애노테이션을 사용하여 HTTP 요청 본문을 매핑함으로써, 클라이언트가 보낸 데이터를 서버에서 처리하고 응답을 생성하는 데 사용할 수 있습니다. 이는 클라이언트와 서버 간의 데이터 통신을 구현하는 데 매우 유용합니다.

DTO

일반적으로 컨트롤러에서 서비스로 데이터를 전달할 때, DTO를 사용하여 데이터를 담아 전달합니다.
컨트롤러는 클라이언트로부터 받은 요청을 처리하고, 필요한 데이터를 서비스 계층에 전달합니다. 이때 DTO 는 데이터를 전달하기 위한 편리한 방법입니다. DTO 는 클라이언트로부터 전송된 데이터를 담아서 컨트롤러에서 서비스로 전달할 수 있으며, 이는 코드를 더 명확하게 작성하고 유지보수하기 쉽게 만듭니다.
따라서 컨트롤러에서 서비스로 데이터를 전달할 때, DTO 를 사용하여 데이터를 전달하는 것이 일반적인 방식입니다. 이렇게 함으로써 데이터 전송 과정이 명확해지고, 데이터의 일관성을 유지할 수 있습니다.

DTO 에서 생성자를 만들어주는 이유

불변성 보장: 생성자를 통해 DTO 객체를 생성할 때 필드 값들을 한 번에 설정할 수 있습니다. 이렇게 하면 객체가 한 번 생성되고 나면 내부의 필드 값들을 변경할 수 없게 됩니다. 이는 DTO 객체의 불변성을 유지하는 데 도움이 됩니다.
코드 간결성: 생성자를 사용하면 객체 생성 과정을 간결하게 만들 수 있습니다. 객체를 생성할 때 모든 필드 값을 지정할 수 있으므로, 별도의 설정 메서드를 호출할 필요가 없습니다.
유지보수성: 생성자를 사용하여 객체를 초기화하면 필드 값들이 잘못 설정되는 경우를 방지할 수 있습니다. 모든 필드를 생성자에서 한 번에 초기화하면 필드 설정과 관련된 로직이 한 곳에 집중되므로, 코드를 이해하고 유지보수하기가 더 쉬워집니다.
데이터 유효성 검사: 생성자 내부에서 입력된 데이터의 유효성을 검사하고 필요한 경우 예외를 던질 수 있습니다. 이를 통해 잘못된 데이터가 객체에 설정되는 것을 방지할 수 있습니다.

요약하면, 생성자를 사용하여 DTO 객체를 초기화하면 불변성을 보장하고 코드를 간결하게 유지할 수 있으며, 유지보수성과 데이터의 유효성을 검사할 수 있습니다.

@AllArgsConstructor

@AllArgsConstructor 어노테이션을 사용하면 클래스 이름과 다른 이름의 생성자를 사용할 수 있다. 왜냐하면 @AllArgsConstructor 는 모든 필드를 인자로 받는 생성자를 생성하기 때문인데 그런 이유에서 생성자의 이름과 클래스의 이름이 다를 수 있다.

@RequestBody

클라이언트의 요청 본문을 받아서 처리할때만 이 어노테이션을 사용한다
-> 생성, 수정
조회 요청은 요청 URL에 쿼리 매개변수나 경로 변수를 포함하여 필요한 정보를 전달한다. 이러한 경우으넨 @RequestParam 이나 @PathVariable 등을 사용하여 요청 매개변수를 받아서 처리할 수 있습니다. 조회 요청은 DTO 를 사용하여 요청 데이터를 받는게 아니라 해당 요청에 필요한 데이터를 URL 매개변수 등으로 전달받아 처리합니다. 이러한 경우 @RequestParam , @PathVariable 사용

void

void는 메서드가 반환하는 값의 타입을 나타내는 키워드입니다. 메서드가 어떤 값을 반환하지 않을 때 사용됩니다. 삭제 메서드(delete)는 단순히 데이터베이스에서 특정 ID에 해당하는 엔티티를 삭제하는 작업을 수행합니다. 이 메서드는 삭제 작업을 수행하고 결과를 반환하지 않기 때문에 반환 타입으로 void를 사용합니다.
반면에 생성 메서드나 조회 메서드는 새로운 엔티티를 생성하거나 데이터를 조회하여 반환해야 하기 때문에 반환 타입이 필요합니다. 예를 들어, 생성 메서드는 새로운 엔티티를 생성하고 그 엔티티의 ID나 다른 정보를 반환할 수 있습니다. 조회 메서드는 특정 조건에 해당하는 데이터를 조회하여 그 결과를 반환합니다. 따라서 생성 메서드나 조회 메서드는 반환할 값을 가지고 있기 때문에 반환 타입으로 void가 아닌 다른 타입을 사용합니다

반환할 타입이 없다는건 변수선언 x 왜냐면 반환을 해서 변수에 저장을 하는 것이기 때문에

update

update 만 엔티티에 메서드를 따로 만들어주는 이유는??
객체의 불변성을 유지하기 위해서다. 객체의 불변성을 유지하는 것은 객체 지향 프로그래밍의 중요한 개념 중 하나이다.
update 메서드를 사용하면 객체의 상태를 변경할 때 헤당 메서드를 통해서만 변경이 가능하다, 이는 객체의 일관성과 안정성을 유지하는 데 도움이 됩니다. 또한, 수정 로직이 여러 곳에 분산되어 있지 않고 한 곳에 집중되어 있어서 코드를 더 쉽게 이해하고 유지보수할 수 있다.
또 다른 이유로는 update 메서드를 통해 수정 로직을 명확히 표현할 수 있기 때문입니다. update 메서드를 사용하면 객체가 가진 필드들을 일일이 수정하는 대신에 하나의 메서드 호출로 모든 필드를 수정할 수 있습니다. 이는 코드의 가독성을 높이고 실수를 줄일 수 있습니다.
수정은 다른 작업과는 달리 데이터의 변경이 일어나는 경우이기 때문에 따로 메서드를 만들어주는것이 일반적이다.

흐름

controller -> service -> repository -> db

Controller: 클라이언트 요청을 받고, 해당 요청에 대한 처리를 담당합니다.
Service: 비즈니스 로직을 처리하고, 필요한 데이터 조작 및 계산을 수행합니다. 데이터베이스와의 상호 작용은 주로 서비스에서 이루어집니다.
Repository: 데이터베이스와의 상호 작용을 추상화하고, 데이터베이스에 접근하는 데 필요한 메서드들을 제공합니다.
Database (DB): 데이터베이스는 실제 데이터가 저장되는 곳으로, CRUD(Create, Read, Update, Delete) 연산이 수행됩니다.

따라서 클라이언트의 요청이 컨트롤러로 전달되고, 컨트롤러에서는 해당 요청을 서비스로 전달하여 비즈니스 로직을 수행합니다. 서비스는 필요에 따라 데이터베이스와 상호 작용하기 위해 레파지토리를 사용합니다. 최종적으로 레파지토리는 데이터베이스와 직접적으로 상호 작용하여 데이터를 읽거나 쓰게 됩니다.

레파지토리는 데이터베이스와의 상호 작용을 추상화하는 역할을 합니다. 이는 일반적으로 데이터베이스에 데이터를 저장하고 검색하기 위한 메서드를 제공합니다. 따라서 레파지토리의 findById() 메서드는 주어진 ID에 해당하는 엔티티를 데이터베이스에서 찾아오는 역할을 합니다. 이렇게 조회된 엔티티는 서비스 레이어로 반환되어 비즈니스 로직을 수행하거나 클라이언트로 응답될 수 있습니다.