데린이 성장 일지

JPA(Java Persistence API)는 자바 ORM 기술에 대한 API 표준입니다.

그렇기 때문에 JPA는 ORM의 장점과 단점을 가지고 있습니다.

ORM

ORM이란 Object Realational Mapping의 약자로 객체와 관계형 데이터베이스를 매핑해주는 것입니다.

장점

객체 지향적인 접근

객체 지향 프로그래밍 언어를 사용하는 애플리케이션과 관계형 데이터베이스 간에는 패러다임의 불일치가 있습니다.

객체는 클래스와 상속, 다형성 등의 개념을 사용하여 데이터를 표현하고, 관련된 동작을 캡슐화합니다.

반면에 관계형 데이터베이스는 테이블과 열, 행 등의 개념을 사용하여 데이터를 저장하고 관리합니다.

ORM은 이러한 불일치를 해결하여 객체 지향적인 코드로 데이터베이스를 다룰 수 있게 해줍니다.

독립성

특정 데이터베이스에 종속되지 않고 객체 지향적인 코드를 작성할 수 있습니다.

생상성 향상

SQL 쿼리를 직접 작성하는 번거로움을 줄일 수 있습니다.

대신 객체 지향적인 코드로 데이터베이스 조작을 수행할 수 있으므로 개발자가 더 쉽게 작업할 수 있습니다.

CRUD 기능을 자동으로 처리하고, 데이터베이스와의 통신을 추상화하여 개발 시간을 단축시킵니다.

유지보수성 향상

객체와 데이터베이스 간의 매핑이 명확해지므로, 코드의 유지 보수가 용이해집니다.

데이터베이스 스키마의 변경이 있을 때도 ORM을 사용하면 코드 수정이 최소화됩니다.

일반적으로 객체와 데이터베이스 사이의 매핑을 설정하는 많은 기능을 제공하여 유지 보수성을 향상시킵니다.

단점

SQL 제어의 어려움

복잡한 조인이나 집계 함수를 포함하는 쿼리를 작성하는 경우에는 네이티브 쿼리(native query)를 사용해야 할 수도 있습니다.

네이티브 쿼리를 사용하게 되면 특정 데이터베이스에 종속될 수도 있습니다.

성능 저하 위험

자동으로 생성되는 쿼리가 많기 때문에 개발자가 의도하지 않는 쿼리로 인해 성능이 저하될 수도 있습니다.

학습 곡선

개념과 기능을 이해하는 데 시간이 걸릴 수 있습니다.

많은 애플리케이션에서 데이터베이스를 활용하지만, 데이터베이스 연결에는 많은 비용이 듭니다.

이 비용을 줄이기 위해 커넥션 풀이라는 개념이 등장했다고 합니다.

커넥션 풀

데이터베이스와 커넥션된 객체를 일정한 수만큼 미리 만들어 넣어두는 컨테이너입니다.

애플리케이션에서 데이터베이스에 대한 조작이 있을 때, 커넥션 풀에서 커넥션을 꺼내와 사용합니다.

다 사용하면 커넥션을 커넥션 풀에 반환합니다.

이렇게 함으로써, 데이터베이스와 연결하고 끊는 비용을 줄이고, 효율적으로 데이터베이스와 통신 할 수 있습니다.

※ 종류는 여러가지 있지만 스프링부트는 성능과 동시성 면에서 우수한 성능을 보이는 HikariCP을 우선적으로 선택합니다. 

스프링 부트에서 영속성 컨텍스트는 Persistence Context라 하며, 데이터베이스와 관련된 작업을 할 때 사용되는 중요한 개념입니다.

영속성 컨텍스트는 엔티티 객체를 관리하고 데이터베이스와의 상호작용을 관리하는 역할을 합니다.

이를 통해 데이터베이스와의 효율적인 상호작용 및 데이터 변경을 추적할 수 있습니다.

※ 여기서 엔티티는 데이터베이스에서 가져온 데이터를 나타내는 자바 객체를 말합니다.

일반적으로 스프링 부트는 JPA, Hibernate와 같은 영속성 프레임워크를 사용하여 엔티티를 관리합니다.

위 이미지에 대해 제가 간략히 이해한바로 말씀드리자면,

• JDBC: java로 데이터베이스를 조작할 수 있게 해주는 인터페이스
• Hibernate: JDBC를 보다 더 간단하고 쉽게 사용할 수 있게 해주는 인터페이스
• JPA: Hibernate를 보다 더 간단하고 쉽게 사용할 수 있게 해주는 인터페이스

※ EntityManager는 영속성 컨텍스트에서 엔티티를 관리하는 객체입니다.

영속성 컨텍스트 특징

1. 엔티티 관리

애플리케이션에서 작업하는 엔티티 객체를 관리하여, 객체의 상태 변화를 추적하고, 데이터베이스와의 동기화를 담당합니다.

2. 엔티티 캐싱

데이터베이스로부터 가져온 엔티티를 key는 id값, value는 entitiy인 Map 형태로 캐싱하여 성능을 향상시킵니다.

이렇게 캐싱하는 것을 1차 캐싱이라고도 합니다.

따라서 동일한 엔티티 조회 시에는 캐시된 엔티티를 반환하여 데이터베이스 부하를 줄일 수 있습니다.

3. 트랜잭션 지원

영속성 컨텍스트는 트랜잭션 범위 내에서 동작합니다.

즉, 트랜잭션이 시작되고 종료될 때까지 영속성 컨텍스트는 엔티티 상태를 추적하고, 변경 내용을 데이터베이스에 반영하지 않습니다.

트랜잭션을 롤백할 경우 영속성 컨텍스트도 변경된 상태를 롤백합니다.

4. 지연 로딩(Lazy Loading)과 즉시 로딩(Eager Loading)

영속성 컨텍스트는 연관된 엔티티를 지연 로딩하거나 즉시 로딩하는 방식으로 데이터를 로드합니다.

이를 통해 애플리케이션의 성능을 최적화할 수 있습니다.

5. 더티 체킹(Dirty Checking)

JPA에서 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷을 만들어 놓습니다.

트랜잭션이 끝나는 시점에서 이 스냅샷과 비교해서 다른 점이 있다면 Update 쿼리를 데이터베이스로 전달합니다.

이러한 더티 체킹은 영속성 컨텍스트가 관리하는 엔티티에만 적용됩니다.

스프링 부트 프로젝트를 하면서 에러 로그에서 프록시 객체라는 단어를 많이 보았습니다.

그래서 프록시 객체에 대해 알아보자 합니다.

프록시 객체란?

프록시 객체는 원본 객체를 대신해서 호출될 객체로, 원본 객체를 감싸서 클라이언트의 요청을 처리하는 중간 단계에 위치합니다.

프록시 객체는 원본 객체와 같은 인터페이스를 구현하고 있어서, 클라이언트는 프록시 객체를 호출하는 것으로 인해 원본 객체의 메소드를 호출하는 것과 같은 효과를 얻을 수 있습니다.

프록시 객체를 사용하는 이유는, 프록시 객체를 통해 원본 객체에 대한 접근을 제어하거나, 부가적인 기능을 제공하기 위해서입니다.

예를 들어, 보안을 위해 원본 객체의 메소드에 접근할 때 권한 검사를 수행하거나, 성능을 개선하기 위해 캐싱을 사용하는 등의 기능을 프록시 객체에서 추가할 수 있습니다.

이렇게 함으로써, 원본 객체의 코드를 변경하지 않고도 클라이언트의 요구사항에 맞추어 기능을 추가하거나 변경할 수 있습니다.

이 프록시 개념은 AOP에서 사용됩니다.

AOP란?

AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 합니다.

관점 지향은 어떠한 로직을 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것입니다.

예를 들어 핵심적인 관점은 비지니스 로직이 될 수 있고, 부가적인 관점은 로깅이 될 수 있습니다.

위의 그림에서 Class A, B, C는 핵심적인 관점이고, 노랑, 파랑, 빨강은 부가적인 관점입니다.

여기서 노랑, 파랑, 빨강 부분을 모듈화하여 재사용하는 것이 AOP의 취지입니다.

Bean? Configuration? Context?

저는 스프링 부트로 프로젝트를 하다보면 Bean, Configuration, Context라는 단어를 자주 접했습니다.

접할 때마다 헷갈려서 개념에 대해 간단하게 정리하고자 합니다.

Bean

스프링에서 빈은 스프링 컨테이너에 의해 생성 및 관리되는 객체를 말합니다. 이 빈들은 스프링 애플리케이션에서 재사용 가능한 구성 요소로, 컨테이너에 등록되어 관리됩니다.

Bean은 다음과 같은 특징이 있습니다.

• 재사용성: 빈들은 재사용 가능한 구성 요소로 설계되어 있으며, 이를 통해 코드의 중복을 줄이고 유지보수성을 향상시킵니다.
• 의존성 주입: 빈들 간의 의존성은 스프링의 DI (Dependency Injection)를 통해 주입되며, 이는 객체 간의 결합도를 낮추고 테스트 가능한 코드를 작성할 수 있게 합니다.

Configuration

스프링에서 설정은 애플리케이션의 구성 정보를 담은 클래스로, 주로 @Configuration 어노테이션을 사용하여 표시됩니다. 이 클래스에서는 빈들의 정의와 의존성을 설정하고 관리합니다.

Configuration은 다음과 같은 특징이 있습니다.

• 빈 정의: 설정 클래스에서는 @Bean 어노테이션을 사용하여 빈들을 정의합니다. 이를 통해 스프링 컨테이너에 등록되고 관리됩니다.
• 외부 설정 연동: 설정 클래스에서는 @ConfigurationProperties 어노테이션을 사용하여 외부 설정 파일의 값을 빈에 주입할 수 있습니다.
• 조건부 빈 등록: @ConditionalOn... 어노테이션을 사용하여 특정 조건에 따라 빈을 등록할 수 있습니다.

Context

스프링 부트 컨텍스트는 스프링 프레임워크의 핵심 기능인 IoC (Inversion of Control)와 DI (Dependency Injection)를 지원하는 컨테이너입니다. 이 컨텍스트는 애플리케이션의 구성 요소들을 관리하고, 객체들 간의 의존성을 관리하여 애플리케이션을 구성하고 실행하는 역할을 합니다.

Context는 다음과 같은 특징이 있습니다.

• 빈 관리: 컨텍스트는 빈(bean)이라 불리는 객체들을 생성하고 관리합니다. 빈은 스프링 애플리케이션에서 재사용 가능한 구성 요소로, 컨텍스트는 이러한 빈들을 생성하고 관리합니다.
• 의존성 주입: 빈들 간의 의존성은 컨텍스트가 관리하며, 이를 통해 객체 간의 결합도를 낮추고 테스트 및 유지보수를 용이하게 합니다.

따라서 일반적인 스프링 애플리케이션에서는 설정 클래스에 @Bean 어노테이션을 사용하여 빈을 정의하고, 이 설정 클래스를 스프링 컨텍스트에 등록하여 빈들이 관리되게 됩니다.

이렇게 하면 컨텍스트가 설정 클래스를 기반으로 빈들을 생성하고 의존성을 주입하게 됩니다.

@Component 외 내가 사용한 어노테이션들은 Bean으로 등록해주는 기능이 있나?

Bean에 대해서 알아보다가 제가 사용했던 @Component, @Repository, @Service, @RestController가 생각이 났습니다.

그래서 Bean의 관점에서 같이 알아보고 간단하게 정리하고자 합니다.

@Component

@Component 어노테이션은 스프링에서 관리하는 빈으로 등록하기 위해 사용되는 가장 기본적인 어노테이션 중 하나입니다.

이 어노테이션을 사용하면 해당 클래스를 스프링의 컨테이너에서 빈으로 인식하게 되어, 의존성 주입과 같은 스프링의 기능을 활용할 수 있습니다.

@Component 어노테이션을 사용하는 클래스는 주로 비즈니스 로직이나 다양한 기능을 수행하는 클래스로서, 스프링 애플리케이션 컨텍스트에 등록되어 다른 클래스에서 이를 주입받아 사용할 수 있습니다.

이 외에도 @Repository, @Service, @Controller 등은 @Component를 확장한 특수한 종류의 어노테이션으로 사용되기 때문에 @Repository, @Service, @Controller를 사용하는 클래스도 빈으로 등록됩니다.

※ @RestController는 @Controller를 확장한 것입니다.