[백엔드 스터디] 5주차 - ORM과 JPA의 추상화 계층 그리고 특징들

Google Developer Student Clubs 1기/GDSC 백엔드 스터디

[백엔드 스터디] 5주차 - ORM과 JPA의 추상화 계층 그리고 특징들

Razelo 2023. 2. 1. 15:48

이번 5주차에서는 본격적으로 JPA를 공부하기에 앞서서 ORM 그리고 JPA는 무엇이며 이러한 것들이 필요한 이유에 대해서 알아보는 시간을 가지고자 한다.

이번 주는 간단한 답변보다는 서술할 수 있는 수준에 초점을 맞추고자 합니다.

주제에 앞서 먼저 ORM와 JPA의 기본인 영속성에 대해 짚고 넘어가고자 합니다.

Persistence

Persistence란 무엇인가?

Persistence 즉 영속성이란 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 말합니다.

영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 됩니다.

즉 휘발성이 있습니다.

Object Persistence인 영구적인 객체는 무엇일까요?

메모리 상의 데이터를 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용해서 영구적으로 저장해서 영속성을 부여하는 개념입니다.

데이터를 데이터베이스에 저장하는 세 가지 방법

JDBC (자바에서 사용)
Spring JDBC (ex: JdbcTemplate)
Persistence Framework (ex: 하이버네이트, Mybatis 등)

Persistence Layer란?

프로그램의 아키텍쳐에서 데이터에 영속성을 부여해주는 계층을 말합니다.

JDBC를 이용해서 직접 구현할 수 있지만 Persistence framework를 이용한 개발이 많이 이뤄지고 있습니다.

Persistence Framework란?

JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발할 수 있으며 안정적인 구동을 보장합니다. Persistence Framework는 SQL Mapper와 ORM으로 구분할 수 있습니다.

ex) JPA, Hibrnate, Mybatis

SQL Mapper란 무엇일까?

Object와 SQL의 필드를 매핑해서 데이터를 객체화하는 기술이다. 객체와 테이블 간의 관계를 매핑하는 것이 아니라, SQL문을 직접 작성하고 쿼리 수행결과를 어떠한 객체에 매핑하여 줄 지 바인딩하는 방법이기에 SQL 의존적인 방법이다.

ex) JdbcTemplate, Mybatis

Mybatis는 무엇일까?

Mybatis는 SQL을 xml 파일로 분리해서 관리하고 SQL 결과와 객체 인스턴스의 매핑을 도와주는 역할을 수행한다. 동적쿼리를 지원해서 다이나믹하게 변경되는 쿼리를 작성할 수 있다.

Mybatis에서 발생 문제

SQL을 개발자가 직접 작성하는 문제
DBMS에 종속적인 문제
비슷한 쿼리를 반복적으로 작성해야 하는 문제
객체와 관계형 테이블 구조간 패러다임 불일치 발생 문제

왜 JPA, Mybatis가 등장했을까?

기존에 JDBC를 사용했을 때 SQL 문이 코드에 섞여 있었고 SQL문을 만들고 요청하는 과정에서 SQL 문 생성 시 String을 붙이고 자르는 등의 작업이 필요해서 SQL문이 조금만 길어져도 번거롭고 관리가 힘들었다. 그래서 코드와 SQL문을 분리해서 관리하기 위해서 JPA, Mybatis 등을 사용하게 되었다.

ORM

ORM은 무엇인가?

ORM은 Object Relational Mapping의 약어입니다. 즉 객체-관계 매핑을 의미합니다. 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 것을 말합니다. 객체 지향 프로그래밍은 클래스를 사용하고 관계형 데이터베이스는 테이블을 사용한다는 개념적 차이가 있습니다. 그래서 둘 사이의 모델 간에 불일치가 존재합니다. 그래서 ORM을 통해서 객체 간의 관계를 바탕으로 SQL을 자동적으로 생성합니다. 이를 통해 불일치를 해결하게 됩니다.

(데이터베이스 데이터 <- 매핑 -> Object 필드) 객체를 통해 간접적으로 데이터베이스 데이터를 다루게 됩니다. 이런 방식을 Persistant API라고도 부르며 예시로는 JPA와 하이버네이트가 있습니다.

CRUD 관련 메소드를 사용하면 자동으로 SQL이 만들어져서 개발자가 반복적인 SQL을 직접 작성하지 않아도 되고, DBMS에 종속적이지 않다. 또한 복잡한 쿼리의 경우 JPQL을 사용하거나 SQL Mapper와 혼용해서 쓸 수 도 있다. 가장 대표적인 기술은 Hibernate이다. 비슷한 기술로는 EclipseLink와 DataNucleus등이 있다.

ORM의 장단점

장점

1. 객체지향적인 코드를 사용할 수 있어서 더 직관적이고 비즈니스 로직에 집중할 수 있게 도와준다.

ORM을 이용하면 SQL Query가 아닌 직관적인 코드(메서드)로 데이터를 조작할 수 있어서 개발자가 객체 모델로 프로그래밍하는 데 집중할 수 있도록 도와준다. 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어든다. 각종 객체애 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려준다. SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 생산성이 증가한다.

2. 재사용 및 유지보수의 편리성이 증가한다.

ORM은 독립적으로 작성되어 있고, 해당 객체들을 재활용할 수 있다. 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는 데 유리하다. 매핑정보가 명확해서, ERD를 보는 것에 대한 의존도를 낮출 수 있다.

3. DBMS에 대한 종속성이 줄어든다.

객체 간의 관계를 바탕으로 SQL을 자동으로 생성하기 때문에 RDBMS의 데이터 구조와 Java의 객체지향 모델 사이의 간격을 좁힐 수 있다. 대부분 ORM 솔루션은 DB에 종속적이지 않다. 종속적이지 않다는 것은 구현 방법 뿐만 아니라 많은 솔루션에서 자료형 타입까지 유효하다. 프로그래머는 Object에 집중함으로서 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요된다. 또한 자바에서 가공할 경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능하다.

DBMS에 의존하지 않음으로써 도메인과 비즈니스 로직 설계에 더 집중할 수 있는 장점

요구사항 변화에 다른 대처 가능한 장점

복잡한 통계성 쿼리보다는 실시간 처리에 적합하다. 왜? JPA에서 제공하는 Native query기능을 사용할 수 있지만 보통 통계는 복잡하고 미세한 쿼리 작업이 필요함. 따라서 그런 상황에선 Mybatis같은 Mapper계열의 방식을 사용하는 것이 효율적일 수 있음.

Native Query란?
@Query 어노테이션을 활용해서 직접 쿼리를 작성할 수 있음.

JPA에서 쿼리를 직접 작성할 수 있는 방법은 JPQL로 작성하는 것과 일반 SQL로 작성하는 것 두 가지가 있다.
(JPQL은 JPA의 일부분으로 정의된 플랫폼 독립적인 객체지향 쿼리 언어이다. 그래서 일반 SQL이 데이터베이스를 바라보고 작성한다면 JPQL은 엔티티 클래스를 바라보고 작성해야 한다. 둘 다 @Query를 활용해 작성하지만 nativeQuery = true라는 옵션을 주면 일반 SQL문임을 명시한다. nativeQuery=false가 디폴트값이다.)

단점

1. 완벽한 ORM으로만 서비스를 구현하기가 어렵다.

사용하기는 편하지만 설계는 매우 신중하게 해야한다. 프로젝트의 복잡성이 커질 경우 난이도 또한 올라갈 수 있다. 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있다. 일부 자주 사용되는 대형 쿼리는 속도를 위해서 SP를 쓰는 등 별도의 튜닝이 필요한 경우가 있다. DBMS의 고유 기능을 이용하기 어렵다.

SP는 Stored Procedure의 약자로 저장 프로시저라고 부릅니다. 미리 준비된 SQL 코드를 데이터베이스에 저장해놓고 이를 함수처럼 호출하는 방식을 의미합니다. 쿼리가 DB에 저장되어 있기 때문에 DB 구조같은 내용이 외부로 노출될 위험이 적어 보안성에서 좋으며, 호출 시 프로시저 명만 사용하기 때문에 네트워크 트래픽이 적어지게 됩니다. 또한 DB에서 저장된 코드를 불러내여 실행하기 때문에 실행 속도가 매우 빠르다는 장점이 있습니다.

ORM VS SP

ORM에서도 저장 프로시저를 사용할 수 있고 SP를 사용한다고 해서 ORM이나 SQL Mapeer를 사용할 수 없는 것이 아니다. 하지만 같은 기능을 사용하는 여러 가지 기술을 동시에 사용하면 유지 보수성 측면에서 좋지 않다.

ORM이 SP에 비해 갖는 장점들은 다음과 같다.

비즈니스 로직을 DB가 아닌 프로그램 코드에 모으기 때문에 로직의 파편화가 적어진다.
DB와의 상호작용 역시 테스트가 필요한데 저장 프로시저에 비해 테스트 구성이 쉽다.
Git과 같은 버전 관리 시스템에서 관리가 편하며 이력 추적이 용이하다.
DB 종류에 독립적이기 때문에 특정 DB만을 사용해야 할 이유가 적어진다.
추상화가 잘 되어 있으며 개발자가 상대적으로 DB에 대한 지식이 적어도 된다.
로직의 재사용성이 증가하고 유지보수가 쉽다.
기존 CI/CD 파이프라인을 사용해서 배포 관리가 가능하다.

ORM의 가장 큰 장점은 생산성이 좋다느 점이다. 현대 개발 패러다임은 성능보다는 생산성 중심이 되어가고 있다. 따라서 생산성은 극한의 튜닝을 통해 성능을 쥐어짜야하는 서비스가 아니라면 ORM을 쓸 여지를 더욱 크게 만든다.

저장 프로시저의 경우 ORM에 비해 갖는 장점들은 다음과 같다.

쿼리가 아닌 프로시저명을 받기 때문에 상대적으로 네트워크 트래픽이 적다.
DB에서 로직을 직접 실행시키기 때문에 속도가 매우 빠르다.
특정 DB에서 제공하는 세밀한 기능들을 직접 사용할 수 있다.
DB 로직만 수정할 경우 컴파일이 필요없이 바로 데이터베이스에 업데이트할 수 있다.
디버깅이 쉽다.

저장 프로시저는 사실 특정 DB에 통달한 DBA가 아니라면 성능상 장점을 크게 얻기는 어렵다. 예전에는 프로시저 방식의 개발을 많이 수행했다. 현 금융권에서는 지금도 그렇게 한다. 하지만 협업의 중요성이 날이 갈수록 커지기에 프로시저 방식은 협업에서 불리하여 선호되지 않는다.

데이터베이스는 비싼 자원이다. 수평적 확장이 쉬운 서버 쪽 자원에 비해서 DB는 스케일 아웃이 힘들다. 로직을 데이터베이스 자체에 넣을 경우 DB의 부하가 매우 커지게 되고 병목 현상이 발생하거나 DB가 뻗을 가능성이 커진다.

2. 프로시저가 많은 시스템에선 ORM의 객체지향적인 장점을 활용하기 어렵다.

이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있다.

프로시저란 넓은 의미로는 어떤 업무를 수행하기 위한 절차를 뜻한다. 즉 프로세스를 절차적으로 기술해 놓은 것을 프로시저라 한다.

The Object-Relational Impedance Mismatch

Mismatch	Description
Granularity	Sometimes you will have an object model which has more classes than the number of corresponding tables in the database. Lets take an example of Person details, we could broke down person details into two classes one is Person and another is Address for code reusability and code maintainability purpose. But assume that to store Person details in database thers is only one table called Person.
Inheritance	RDBMSs do not define anyhing similar to Inheritance which is natural paradigm in object-oriented programming languages.
Identity	A RDBMS defines exactly ont notion of 'sameness': the primary key. Java, however, defines both object identity(a==b) and object equality (a.equals(b))
Associations	Object-oriented languages represent associations using object references whereas an RDBMS representation an association as a foreign key column.
Navigation	The ways you access objects in Java and in a RDBMS are fundamentally different. In Java, you navigate from one association to another walking the object network (graph). For example, aUser.getBilingDetails().getAccountNumber(). This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINS and select the targeted entities before you start walking the object network.

Granularity (세분성)

경우에 따라 데이터베이스에 있는 해당 테이블 수보다 더 많은 클래스를 가진 객체 모델을 가질 수 있다.

1) Coarse Granularity

2) Fine Granularity

Inheritance (상속)

RDBMS는 객체지향 프로그래밍 언어의 자연적 패러다임인 상속과 유사한 것을 정의하지 않는다. 즉 상속의 개념이 없다.

Identity (일치)

RDBMS는 'sameness'라는 하나의 개념을 정확히 정의하는데 바로 기본키(primary key)이다. 그러나 자바에서는 객체 식별(a==b)과 객체 동일성(a.equals(b))를 모두 정의한다. RDBMS에서는 PK가 같으면 서로 동일한 record로 정의하지만, Java에서는 주솟값이 같거나 내용이 같은 경우를 구분해서 정의한다.

Associations (연관성)

객체지향 언어는 객체 참조(reference)를 사용하는 연관성을 나타내는 반면, RDBMS는 연관성을 외래키(foreign key)로 나타낸다.

Navigation (탐색/순회)

Java 및 RDBMS에서 객체에 액세스하는 방법은 근본적으로 다르다. Java에서는 하나의 연결에서 다른 연결로 이동하면서 탐색/순회한다. (그래프 형태) 예를 들어 aUser.getBilingDetails().getAccountNumber() 이는 RDBMS에서 데이터를 검색하는 효율적인 방법이 아니다. RDBMS에서는 일반적으로 SQL 쿼리 수를 최소화하고 JOIN을 통해서 여러 엔티티를 로드하고 원하는 대상 엔티티를 선택(select)한다.

Why we need ORM?

- 최소 개발 시간과 더 높은 생산성

- 더 나은 애플리케이션 설계 코드 생성

- 최소 테스트 시간 및 노력

- 간소화된 개발을 위한 코드 재사용

- SQL 인젝션 공격으로부터 보호

JPA

JPA의 추상화 계층: Spring Data JPA - JPA - Hibernate 추상화 구조

Spring Data JPA는 Spring 프레임워크에서 JPA를 쉽게 사용하기 위해 만든 컴포넌트이다. Spring Data JPA는 JPA를 한 단계 더 추상화시킨 Repository 인터페이스를 제공한다. 개발자는 이를 확장해서 사용할 수 있다. 간단한 이름 규칙에 맞는 메소드를 작성함으로써 쉽게 영속성 프레임워크 기능을 사용할 수 있다.

Class Level Architecture

아래 이미지는 JPA의 클래스 수준 아키텍쳐이다. JPA의 핵심 클래스와 인터페이스를 보여준다.

Units
EntityManagerFactory	EntityManager의 factory클래스이다. 여러 EntityManager 인스턴스를 생성하고 관리한다.
EntityManager	인터페이스이다. 객체에 대한 지속성 자업을 관리한다. Query인스턴스를 위한 factory 처럼 작동한다.
Entity	엔티티는 지속성 개체이며, 데이터베이스에 레코드로 저장된다.
EntityTransaction	EntityManageer와 일대일 관계를 맺고 있다. 각 EntityManager에 대해 작업은 EntityTransaction 클래스에 의해 유지된다.
Persistence	EntityManagerFactory 인스턴스를 가져오는 정적 메서드가 포함되어 있다.
Query	이 인터페이스는 기준을 충족하는 관계형 객체를 얻기 위해 각 JPA 공급업체에 의해 구현됩니다.

위 클래스 및 인터페이스는 엔티티를 레코드로 데이터베이스에 저장하는 데 사용됩니다. 데이터베이스에 데이터를 저장하기 위한 코드를 작성하는 노력을 줄임으로써 프로그래머 들이 클래스를 데이터베이스 테이블과 매핑하기 위한 코드 작성과 같은 더 중요한 활동에 집중할 수 있도록 도와줍니다.

JPA Class Relationships

위 아키텍쳐에서 언급되는 클래스와 인터페이스 사이의 관계는 javax.persistence 패키지에 속한다. EntityManagerFactory와 EntityManager의 관계는 일대일 관계이다. EntityManager 인스턴스의 팩토리 클래스이다. EntityManager와EntityTransaction의 관계는 일대일 관계이다. 각 EntityManager 작업에 대해 EntityTransaction 인스턴스가 있다. EntityManager 와 Query의 관계는 일대일이다. 하나의 EntityManager 인스턴스를 사용해서 여러 쿼리를 실행할 수 있다.

EntityManager와 Entity 의 관계는 일대일 관계이다. 하나의 EntityManager 인스턴스가 여러 엔티티를 관리할 수 있다.

Small talk

DB는 역사가 오래되었다. ORM은 사실 DB쪽 입장이 아니라 프로그래머 입장을 고려해서 나온 개념이다. DB의 컬럼을 멤버 변수로 보자는 개념이다. foreign key relationship을 composition으로 본다.

프로그래머가 SQL쿼리를 짜지 않는게 좋다. 그런데 사람 손으로 짜는 것보다 반드시 최적화된 쿼리가 나가리란 법은 없다. 그런 부분이 ORM의 적용 시기를 늦췄다고 볼 수 있다. DBA의 Job Security 때문에 적용이 늦었다는 얘기도 있긴 하다.

애플리케이션의 모든 동작이 코드로 이뤄지는 게 가장 옳은 사례가 될 수 있다. DB first 방식이 있다. DB를 먼저 만들고 그 DB 테이블에 맞는 오브젝트를 만들어서 서로 연결하는 개념이다. 이게 일부 프레임워크에서 주로 쓰는 방식인데 이게 Code first가 되어야 한다. 이건 코드를 짜고 오브젝트를 만들었을때 이걸 그냥 실행만 시키면 알아서 ALTER TABLE, CREATE TABLE 등으로 수정한다. 이 방향이 더 좋다고 본다. DB first 보다 Code first가 더 옳은 방향이다.

DDD가 나온 이유가 DB만 전문으로 하는 프로그래머들이 OOP의 개념이 없어서 중구난방의 스파게티 코드를 짰었다. 이걸 막기 위해 DDD가 나왔다. ORM이 들어오면 매핑 개념이기에 OOP가 웹프로그래밍에서도 이제 일등 시민이 된다는 얘기가 있다. 즉 핵심이 될 수 있단 소리다. 그래서 .ORM은 올바른 프로그래밍이나 소프트 엔지니어링의 원칙을 만드는 디딤돌이 될 수 있다. 그래서 ORM은 꼭 알아두는게 좋다.

엔티티 프레임워크가 반드시 성능이 제일 빠르진 않다. 최적화를 할 여지를 내부적으로 남겨두는 경우도 있다. ORM을 통해 웹 생태계의 패러다임이 변할 수 있다.

jsonfile 등이 있는데 jsonfile도 손으로 직접 필드를 넣는 사람이 있다. 이것도 흐름에 역행이다. 이것도 오브젝트에서 생성하는 방향이 맞다. json < - > object 변환 간에 다양한 테크닉을 넣을 수도 있다. 자바쪽은 Gson으로 지원되는 것으로 알고 있다. Object라는 개념 자체가 SQL을 순수 string으로 접근하는 방법보다는 훨씬 실수할 여지가 적다.

면접 예상 질문

1. ORM이 등장하게 된 배경은 무엇일까요?

2. ORM의 장단점에 대해 말해보세요.

장점:

객체지향적인 코드를 사용할 수 있어서 더 직관적이고 비즈니스 로직에 집중할 수 있게 도와준다.

재사용 및 유지보수의 편리성이 증가한다.

DBMS에 대한 종속성이 줄어든다.

단점:

완벽한 ORM으로만 서비스를 구현하기가 어렵다.

프로시저가 많은 시스템에선 ORM의 객체지향적인 장점을 활용하기 어렵다.

3. 객체와 DB 테이블 간 불일치에 대해 설명해보세요.

Granularity (세분성)

Inheritance (상속)

Identity (일치)

Associations (연관성)

Navigation (탐색/순회)

4. 영속성(Persistence)이란 무엇일까요?

Persistence 즉 영속성이란 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 말합니다.

영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 됩니다.

즉 휘발성이 있습니다.

5. SQL Mapper란 무엇일까요?

ex) JdbcTemplate, Mybatis

6. JPA에서 쿼리를 작성할 수 있는 두 가지 방법은 무엇이 있을까요?

JPQL사용과 일반 SQL문 작성 방법이 있습니다.

7. JPA를 사용하는 와중에도 대형 쿼리를 질의해야하는 경우 튜닝을 위해 OO을 사용할 수 있습니다. OO이란 무엇일까요?

SP 즉 저장 프로시저를 사용할 수 있습니다.

SP는 Stored Procedure의 약자로 저장 프로시저라고 부릅니다. 미리 준비된 SQL 코드를 데이터베이스에 저장해놓고 이를 함수처럼 호출하는 방식을 의미합니다. 쿼리가 DB에 저장되어 있기 때문에 DB 구조같은 내용이 외부로 노출될 위험이 적어 보안성에서 좋으며, 호출 시 프로시저 명만 사용하기 때문에 네트워크 트래픽이 적어지게 됩니다. 또한 DB에서 저장된 코드를 불러내여 실행하기 때문에 실행 속도가 매우 빠르다는 장점이 있습니다.

8. 객체 지향 언어에서 객체에 접근하는 방법과 DB에서의 테이블 접근 방법은 근본적으로 다릅니다. 어떻게 다를까요? 이를 Navigation 즉 탐색 즉면에서 설명해보세요.

9. 왜 우리는 ORM을 써야 할까요?

- 최소 개발 시간과 더 높은 생산성

- 더 나은 애플리케이션 설계 코드 생성

- 최소 테스트 시간 및 노력

- 간소화된 개발을 위한 코드 재사용

- SQL 인젝션 공격으로부터 보호

10. Code first 방식과 DB first 방식 중 어떤 방식이 더 옳은 방향이라고 생각하시나요?

Code first 방식이 더 옳은 방향이라고 생각합니다. JPA에서 SQL문을 사용하지 않고 코드 상에서 메서드를 활용해서 DB의 기능을 활용할 수 있는 것처럼 어플리케이션의 모든 동작이 코드로 이뤄지는게 나은 방향이라고 생각합니다.

(애플리케이션의 모든 동작이 코드로 이뤄지는 게 가장 옳은 사례가 될 수 있다. DB first 방식이 있다. DB를 먼저 만들고 그 DB 테이블에 맞는 오브젝트를 만들어서 서로 연결하는 개념이다. 이게 일부 프레임워크에서 주로 쓰는 방식인데 이게 Code first가 되어야 한다. 이건 코드를 짜고 오브젝트를 만들었을때 이걸 그냥 실행만 시키면 알아서 ALTER TABLE, CREATE TABLE 등으로 수정한다. 이 방향이 더 좋다고 본다. DB first 보다 Code first가 더 옳은 방향이다.)

11. ORM vs SP에 관한 주제로 개인적으로 어떤 걸 선호하시는지 말씀해주세요.

때에 따라 다르겠지만 ORM을 선호합니다. 최근 개발 패러다임이 생산성을 중요시하고 있고 협업을 중요시하고 있기 때문에 그에 불리한 SP는 극한의 성능이 필요할 때를 제외하고는 ORM이 더 나은 선택지라고 생각합니다.

아래 링크에서 많은 도움을 받았습니다.

감사합니다.

ORM

- https://gmlwjd9405.github.io/2019/02/01/orm.html

- http://www.incodom.kr/ORM#h_702209f3f35878a32ee91352ddc6bbe7

- https://sm-studymemo.tistory.com/95

- https://www.dnsstuff.com/why-do-we-need-object-relational-mapping

JPA

- https://junhyunny.github.io/spring-boot/jpa/java-persistence-api/

- https://jforj.tistory.com/90

SQL Mapper

- https://deveun.tistory.com/entry/SQL-Mapper%EC%99%80-ORM-%EC%B0%A8%EC%9D%B4

JPA architecture

- https://velog.io/@modsiw/JPAJava-Persistence-API%EC%9D%98-%EA%B0%9C%EB%85%90

- https://dejavuhyo.github.io/posts/spring-boot-jpa-architecture/

Stored Procedure

- https://kayuse88.github.io/database-logic/

저작자표시 비영리 변경금지

'Google Developer Student Clubs 1기 > GDSC 백엔드 스터디' 카테고리의 다른 글

[백엔드 스터디] 7, 8주차 - JPA 연관관계 및 영속성 전이 (0)	2023.02.15
[백엔드 스터디] 6주차 - JPA 영속성 컨텍스트 (0)	2023.02.06
[백엔드 스터디] 4주차 - 컴포넌트 스캔 그리고 의존관계 자동 주입 (0)	2023.01.27
[백엔드 스터디] 3주차 - Bean Scope 그리고 Bean 생명주기 (0)	2023.01.07
[백엔드 스터디] 2주차 - Spring Container(ApplicationContext) (0)	2023.01.05

현재글[백엔드 스터디] 5주차 - ORM과 JPA의 추상화 계층 그리고 특징들

Razelo 기술노트