Persistence (영속성)

데이터를 생성한 프로그램이 종료되더라도 사라지지않는 데이터의 특성

기존 객체지향 애플리케이션에서 DB적용하기 전까지 객체상태는 단지 메모리에서만 존재하여 프로그램이 종료되면 그 상태를 잃어버렸다. = 영속성을 가지지않았다.
다음 프로젝트에서는 프로그램이 종료되더라도 다시 같은 상태를 가지는 객체로 만들어 내기 위해 객체의 상태를 데이터베이스에 저장했다. = 객체에게 영속성을 부여

Mark Rechards의 소프트웨어 아키텍쳐 패턴

Persistence 계층에서 도메인 모델인 객체에 영속성을 부여하는 역할을 한다.

Persistence를 언급한 이유 ?

Persistence layer를 어떻게 구현하느냐에 따라 JDBC / SQL Mapper / ORM을 비교할 수있다.

Persistence Layer 구현하는 방법

1. JDBC
2. Persistence Framework


JDBC

Java Database Connectivity
- 자바에서 데이터베이스에 접속 할 수있도록 하는 자바 API
- 자바 애플리케이션에서 DBMS에 종속적이지 않고 하나의 JDBC API를 이용해서 DB작업을 처리
- JDBC 인터페이스를 구현한 각각의 DBMS 드라이버만 갈아끼우면 어느 DB에서든 접근할 수있다.
- JDBC API를 사용할 경우 하나의 자바 응용 프로그램에서 JDBC 드라이버를 제공하는 어떤 종류의 관계형 DBMS에도 접근이 가능
- 여행할때 챙겨가는 어댑터역할


기존 프로젝트 JDBC 절차

1. 드라이버로드
2. Connection 객체생성 : DB와 연결하는 통로역할
3. Statement 객체생성 : 쿼리문 생성 및 실행
4. ResultSet : SQL의 결과물이있으면 ResultSet객체 생성 후 필요한 데이터를 얻음
5. 작업이 끝나면 반대순서로 자원해제

이것을 코드로 옮기면?

- 연결 파라미터 정의
- 연결 오픈
- SQL문 지정
- 파라미더 선언과 파라미터 값 제공
- Statement 준비와 실행
- 결과를 반복하는 루프 설정
- 각 이터레이션에 대한 작업 수행
- 모든 예외 처리
- 연결, Statement, resultset닫기

JDBC 사용 후 .. 단점

- 간단한 SQL 실행하는데도 중복된 코드 반복사용
- DB에 따라 일관성 없는 정보를 가진채로 Checked Exception(SQL Exception)처리
- Connection과 같은 공유 자원을 제대로 릴리즈(반환) 해주지 않으면서 시스템의 자원이 바닥나는 버그발생->수동으로 잡아줌


Persistence Framework

JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발

Persistence Framework종류

1. SQL Mapper
2. ORM


SQL Mapper
SQL을 직접 작성
직접 작성한 SQL문의 질의결과과 객체의 필드를 매핑하여 데이터를 객체화


JDBC만 사용했을때 ..

더보기

- 연결 파라미터 정의

- 연결 오픈

- SQL문 지정

- 파라미더 선언과 파라미터 값 제공

- Statement 준비와 실행

- 결과를 반복하는 루프 설정

- 각 이터레이션에 대한 작업 수행

- 모든 예외 처리

- 연결, Statement, resultset닫기

- 단순한 조회 기능을 위해 일일히 코드로 작성하고 객체로 반환하기 위해 resultset으로 값을받아 반환

JDBC Template 사용했을때

동일한 쿼리수행이지만 핵심적으로 해야할 작업만 해주면 나머지 JDBC Template이 해줌
- 연결 파라미터 정의
- SQL문 지정
- 파라미더 선언과 파라미터 값 제공
- 각 이터레이션에 대한 작업 수행

-> 쿼리 수행 결과와 객체의 필드 맵핑
-> JDBC에서 반복적으로 해야하는 작업들을 대신해줌
-> 실행할 SQL과 바인딩할 파라미터를 넘겨주거나 쿼리 실행결과를 어떤 객체에 넘겨받을지만 지정하면된다.

Mybatis

-반복적인 JDBC 프로그래밍을 단순화
-SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL을 분리하여 관리
- 순수 JDBC만 사용하면 결과를 가져와서 객체의 인스턴스를 매핑하기 위해 많은 코드들이 필요하다. 마이바티스는 코드들을 작성하지 않아도 된다.

- 보라색 부분인 매버 인터페이스와 매핑 파일만 잘 구현하면 객체의 필드와 SQL문이 매핑된다.
- 매퍼 인터페이스 구현체는 마이바티스에서 자동생성

1. mapper태그에 namespace = 매핑할 인터페이스 경로
2. select, insert, update 등 태그에 실제 동작할 쿼리를 명시
id = 매핑할 메서드명
parameterType = 파라미터 타입
resultType = 반환 값의 타입

Mybatis 동적쿼리를 지원한다.

- 상황에 따라 분기처리를 통해 쿼리를 동적으로 만든다.
- 동적쿼리를 이용해 다이나믹한 쿼리작성이 가능

Mybatis 사용하면 ..

-자동으로 Connection 관리를 해주면서 JDBC를 사용할 때의 중복 작업 대부분을 없애준다.
-복잡한 쿼리나 다이나믹하게 변경되는 쿼리 작성이 쉽다.
-관심사 분리 : DAO로 부터 SQL문을 분리하며 코드의 간결성 및 유지보수성 향상

SQL을 직접 다룸으로 생기는 문제점 ..

- 특정 DB에 종속적으로 사용하기 쉽다.
- 테이블마다 비슷한 CRUD SQL = DAO 개발이 매우 반복되는 작업
- 테이블 필드가 변경될 시 이와 관련된 모든 DAO의 SQL문 , 객체의 필드 등 수정해야한다.
- 코드상으로 SQL과 JDBC API를 분리했어도 논리적으로 강한 의존성을 가지고 있다.

-> DB에 종속적이지 않기위함이 JDBC의 컨셉이었으나 사용하는 쿼리 문법이나 데이터 타입은 DB마다 조금씩 다르고 쿼리문에 직접 작성할 경우 특정 DB에 종속된다
-> DAO를 열어서 어떤 SQL이 실행되는지 확인하고 수정해야함..

관계형 DB와 객체간의 패러다임 불일치


패러다임 불일치 문제

객체지향 RDB
추상화, 상속, 다형성 데이터 중심의 구조

각각 지향하는 목적이 다르기 때문에 사용방법과 표현방식에 차이가 생긴다
- RDB 테이블은 객체의 상속개념이없다.
- 공통부분을 슈퍼타입으로 묶고 서브타입에서 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성을 가짐
- 객체는 참조를 사용해 다른 객체와 연간관계 가짐
- 테이블은 외래키를 사용해 다른 테이블과 연관관계 가짐
- 만약 객체를 테이블 연관관계에 맞춰 모델링하면 객체지향 특징을 버린다. (테이블에서 저장하거나 조회할때는 편리하지만 ..)
- 객체지향 모델링하면 CRUD 에 어려움


ORM

Object Relational Mapping
객체와 관계형 DB를 맵핑
SQL Query가 아닌 직관적인 코드로 데이터 조작
- 객체간의 관계를 바탕으로 SQL문을 자동으로 생성하고 직관적인 메서드로 데이터를 조작

JPA

현재 자바 진영의 ORM에 대한 API 표준 명세

객체의 참조로 연관관계 저장 가능

ORM 장단점

장점 단점
패러다임 불일치 문제 해결
객체지향언어의 장점을 활용 할 수있다.
복잡한 쿼리 사용이 어려움
JPA에서는 SQL과 유사한 기술인 JPQL 지원
물론 SQL 자체 쿼리를 작성할 수 있도록 지원
SQL Mapper와 혼용사용 가능
생산성
반복적인 CRUD용 SQL을 작성할 필요 X
성능이슈
데이터 접근 추상화, 벤더 독립성
데이터 베이스 벤더마다 조금씩 다른 데이터 타입 , SQL을 손쉽게 해결
높은 러닝커브
유지보수
필드추가, 삭제시 관련 CRUD 쿼리를 직접 수정하지않고 엔티티만수정
 

ORM은 객체와 RDB 두 기둥위에 있는 기술
객체지향스럽게 코드를 작성하고 싶은데 DB가 관계DB일 경우 객체지향스럽게 쓸 수 없다. 왜냐면 중간에 매핑하기가 힘들다. 객체를 쿼리로 바꾸기 등..ORM이라는 기술을 쓰면 그 간극을 프레임워크가 메워준다.
좀 더 객체지향적인 코드 작성이 가능 그런데 이런것은 이론적인 내용이다.
실무에서는 기승전 DB이다. 장애의 90%는 DB에서 발생한다.
성능의 90% DB에서 발생한다. 웹어플리케이션, 서버어플리케이션은 데이터 중심적인 과제들을 수행하는게 많다. ->데이터를 얼마나 빨리 조회하고 얼마나 잘 저장하느냐, 안전하게 보관하느냐가 중요하다.
시간이 지나면 자바,객체가 없어지고 데이터는 안안없어진다.
자바가 스칼라,코틀린, 타입스크립트 등으로 바뀔 수 있다.
근데 관계형DB가 바뀔 확률은 훨씬 낮다.
그래서 관계형DB를 잘 다루는것이 중요하다.

관계형 DB를 설계할 줄 알고 객체지향 설계를 할 줄 알아야 ORM을 쓸 수 가있다.
RDB에 대해 깊게 공부하고 객체에 대해 잘알고서 ORM을 써야한다.
관계형 DB 열심히 하기 .. 시간이 갈 수록 더 중요해질것..
관계형DB,객체를 잘 숙지 한뒤에 그 위에 ORM얹어서 공부하기

'* > What I did today' 카테고리의 다른 글

11/5 (함께자라기)  (1) 2021.11.06
11/03  (0) 2021.11.03
CPU를 극단적으로 사용하는 애플리케이션  (0) 2021.10.03
URL Scheme  (0) 2021.10.02
9/23  (0) 2021.09.24
9/21  (0) 2021.09.21
9/20  (0) 2021.09.20
09/13  (0) 2021.09.13

+ Recent posts