ses2

자바 빈이 뭔데 씹덕아! 자바콩!자바콩! - 윤영현

스프링 프로젝트를 하면서 @Bean이라는 어노테이션을 자주 보게되었는데

이게 뭔지 정확하게 이해가 안돼서 정리해 보고자 한다.

1. 스프링 빈

스프링 Ioc 컨테이너가 관리하는 객체를 빈(Bean)이라고 한다.

자바 어플리케이션은 어플리케이션 동작을 제공하는 객체들로 이루어져 있습니다.
이때, 객체들은 독립적으로 동작하는 것 보다 서로 상호작용하여 동작하는 경우가 많습니다.
이렇게 상호작용하는 객체를 '객체의 의존성'이라고 표현합니다.

스프링에서는 스프링 컨테이너에 객체들을 생성하면 객체끼리 의존성을 주입(DI)하는 역할을 해줍니다.
그리고  스프링 컨테이너에 등록한 객체들을 '빈'이라고 합니다.

먼저 스프링 Ioc에 대해 먼저 알아보자.

IoC(Inversion Of Control)

IoC(제어 반전)이란, 객체의 생성, 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는 것을 의미합니다.

컴포넌트 의존관계 설정(Component dependency resoulution), 설정(Configuration) 및 생명주기(LifeCycle)을 

해결하기 위한 디자인 패턴(Design Pattern)입니다.

IoC 컨테이너

컨테이너? - 컨테이너는 보통 객체의 생명주기를 관리, 생성된 인스턴스들에게 추가적인 기능을 제공하도록 하는 것
스프링 프레임워크도 객체를 생성하고 관리하고 책임지고 의존성을 관리해주는 컨테이너가 있는데,

왜 이름이 컨테이너..?

내가 아는건 이런 컨테이넌데 어디서 튀어나와서 컨테이너인척 하는거야..

위에거 다 해주면 그냥 매니저라고 하던가...

인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해줍니다.
객체관리 주체가 프레임워크(Container)가 되기 때문에 개발자는 로직에 집중할 수 있는 장점이 있습니다.

아하! 그럼 내가 관리 안하고 손놓고 있어도 애가 해주는구나!

• IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리한다.
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다.
• 개발자들이 직접 POJO를 생성할 수 있지만 컨테이너에게 맡긴다.
• 개발자는 비즈니스 로직에 집중할 수 있다.
• 객체 생성 코드가 없으므로 TDD가 용이하다.

Ioc 컨테이너가 객체의 생성을 책임진다는데 내가 하나씩 써주는건데 왜 쟤가 하는척함? 

POJO? 푸조가 뭐임 푸주는 아는데

POJO(Plain Old Java Object)에 대해 알아보자 

대충 순수하고 오래된 자바 객체?를 있어보이게 쓴말이라고한다.

스프링(Spring)에서의 POJO
스프링 프레임워크는 IoC(Inversion of Control, 제어의 역전) 컨테이너 안에서 POJO를 구성 및 관리하는 것이 가장 핵심으로 POJO를 매우 잘 다루는 프레임워크가 스프링 프레임워크이다.
Java EE 등을 사용할 때에 비해서 특정 인터페이스를 구현하거나 상속 할 필요 없고 라이브러리를 지원하기에 용이하며 객체 또한 가벼운 것이 특징이다.

확장이나, 인터페이스 구현, 어노테이션같은 양념이 들어간건 순수(Plain)하지 않다. 그래서 포조가 아님 

IOC는 두개로 분류할수 있따

바로 DL(Dependency Lookup) 과 DI(Dependency Injection) 로 나눠지는데

• DL : 저장소에 저장되어 있는 Bean에 접근하기 위해 컨테이너가 제공하는 API를 이용하여 Bean을 Lookup하는 것
• DI : Spring에서 새롭게 지원하는 IoC의 한 형태로써 각 계층 사이, 각 Class 사이에 필요로 하는 의존관계가 있다면 이를 컨테이너가 자동적으로 연결시켜 주는 것(@Autowired, @Qualifier)으로 각 Class 사이의 의존관계를 Bean 설정 정보를 바탕으로 컨테이너가 자동적으로 연결해 주는 것이다.

DL 사용시 컨테이너 종속이 증가하기 때문에 주로 DI를 사용합니다.

라고 하니 DI만 써야겠다

어려운말

스프링 컨테이너에 Bean을 등록하는 두 가지 방법
빈을 등록하는 방법은 기본적으로 두 가지 방법이 있다고 한다.
1.  @Component 컴포넌트 스캔과 자동 의존관계 설정
2. 자바 코드로 직접 스프링 빈 등록

1. 컴포넌트 스캔과 자동 의존관계 설정

스프링 부트에서 사용자 클래스를 스프링 빈으로 등록하는 가장 쉬운 방법은 클래스 선언부 위에 @Component 어노테이션을 사용하는 것입니다. 

@Controller, @Service, @Repository는 모두 @Component를 포함하고 있으며

해당 어노테이션으로 등록된 클래스들은 스프링 컨테이너에 의해 자동으로 생성되어 스프링 빈으로 등록됩니다.

2. 자바 코드로 직접 스프링 빈 등록

이번에는 수동으로 스프링 빈을 등록하는 방법에 대해 알아보겠습니다.

수동으로 스프링 빈을 등록하려면 자바 설정 클래스를 만들어 사용 해야 합니다.

정 클래스를 만들고  @Configuration 어노테이션을 클래스 선언부 위에 추가하면 됩니다.

그리고 특정 타입을 리턴하는 메소드를 만들고, @Bean 어노테이션을 붙여주면 자동으로 해당 타입의 빈 객체가 생성됩니다. 

MemberRepository는 인터페이스이고, MemoryMemberRepository가 구현체이기 때문에  MemoryMemberRepository를 new 해줍니다.

스프링 컨테이너가 관리하는 객체를 빈(Bean)이라고 하고,

이 빈들을 관리한다는 의미로 컨테이너를 빈 팩토리(BeanFactory) 라고 부릅니다.

*출처

https://tecoble.techcourse.co.kr/post/2021-05-16-dto-vs-vo-vs-entity/

프로젝트를 진행하는데 VO와 DTO, ENTITY같은 말이 자주 들렸다.

추상적으로 남들 하는말만 귀에 담아서 대충 이해했었는데

프로젝트 진행에 자꾸 막히니깐 내가 기초를 잘 못잡은 건가? 싶어서 정리를 한번 해보려고 한다.

DTO

먼저 최근에 가장 많이 쓴 DTO는 데이터 전송 계층으로 알고 있다.

단순히 원하는 데이터만 주고 받으려고 ResponseDto, RequestDto와 같이 만들어서 사용했는데

말그대로 데이터 전송만이 목적이다 보니 레코드 타입으로 만들어서 아래처럼 작성했었다.

그럼 이제 DTO가 뭔지 알아보도록 하자.

DTO(Data Transfer Object)

DTO는 데이터를 전달하기 위한 객체이다. 계층간 데이터를 주고 받을 때, 데이터를 담아서 전달하는 바구니로 생각할 수 있다. 여러 레이어 사이에서 DTO를 사용할 수 있지만, 주로 View와 Controller 사이에서 데이터를 주고 받을 때 활용한다 .DTO는 getter/setter 메소드를 포함한다. 이 외의 비즈니스 로직은 포함하지 않는다.

라고 한다.

내가 작성한 위와 같은 코드의 경우 불변 객체인 record로 작성했기 때문에 데이터를 전달하는 과정에서 데이터가 변조되지 않음을 보장할 수 있다.

VO(Value Object)

VO는 값 자체를 표현하는 객체이다. VO는 객체들의 주소가 달라도 값이 같으면 동일한 것으로 여긴다. 예를 들어, 고유번호가 서로 다른 만원 2장이 있다고 생각하자. 이 둘은 고유번호(주소)는 다르지만 10000원(값)은 동일하다.

VO는 getter 메소드와 함께 비즈니스 로직도 포함할 수 있다. 단, setter 메소드는 가지지 않는다. 또, 값 비교를 위해 equals()와 hashCode() 메소드를 오버라이딩 해줘야 한다.

vo는 다음에 다시 추가하도록 하겠다.

Entity

Entity는 실제 DB 테이블과 매핑되는 핵심 클래스이다. 이를 기준으로 테이블이 생성되고 스키마가 변경된다. 따라서, 절대로 Entity를 요청이나 응답값을 전달하는 클래스로 사용해서는 안 된다.

Entity는 id로 구분된다. 그리고 비즈니스 로직을 포함할 수 있다.

package com.example.study.board.domain;

import com.example.study.support.MySchemaConstants;
import com.example.study.support.UuidBaseEntity;
import lombok.*;
import javax.persistence.*;
import java.time.OffsetDateTime;
import java.util.UUID;

import static com.example.study.support.Constants.DEFAULT_TIMEZONE_ID;

@Entity
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Table(
        name = MySchemaConstants.TB_BOARD,
        schema = MySchemaConstants.SCHEMA
)
public class Board extends UuidBaseEntity {
    public UUID memberId;
    public String nickName;
    @Column(name = "board_num", insertable = false, updatable = false)
    public Long boardNum;
    public String title;
    public String content;
    // 빌더로 생성을 할 때 기본으로 넣어주는 값
    @Builder.Default
    public OffsetDateTime createdAt = OffsetDateTime.now(DEFAULT_TIMEZONE_ID);
    public OffsetDateTime updatedAt;
    public OffsetDateTime deletedAt;
}

위의 코드에서는 Id를 uuidBaseEntity에서 상속받아서 쓰기때문에 @Id 어노테이션을 사용해 만들지않았지만 

원래는

public class Board {
    @Id
    public Long Id;
    public UUID memberId;
    public String nickName;
    @Column(name = "board_num", insertable = false, updatable = false)
    public Long boardNum;
    public String title;
    public String content;
    // 빌더로 생성을 할 때 기본으로 넣어주는 값
    @Builder.Default
    public OffsetDateTime createdAt = OffsetDateTime.now(DEFAULT_TIMEZONE_ID);
    public OffsetDateTime updatedAt;
    public OffsetDateTime deletedAt;
}

와 같이 아이디를 정의해줘야한다.

세 객체 비교

분류DTOVOENTITY