Persistence Framework는 "영속성 프레임워크"라고도 불린다.
앞서 말했듯 영속성이라는 것은 데이터가 사라지지 않는 성질이라고 이해하면 될 것이며, 프레임워크도 앞서 말했듯 SW 구체적인 부분에 대한 설계 및 구현을 쉽게 하기 위해 재사용이 가능한 클래스들을 제공하는 것이다.
즉, Persistence Framework를 해석하자면 "데이터가 사라지지 않게 DB에 저장하는 로직에 대한 설계 및 구현을 쉽게 하기 위하여 만든 SW"라고 할 수 있을 것이다.
하지만 이렇게만 설명하면 "JDBC도 영속성 프레임워크 아니야?"라고 생각할 수도 있다.
하지만 JDBC를 보면 Connection을 연결하고 이를 통해 Statement를 얻은 다음 ResultSet을 가지고 오는 과정을 거친다. 이런 중간 과정들은 매번 DB를 활용할 때마다 반복되어야 하고, (Spring JDBC에서는 그 과정이 조금 감소되긴 하였지만) 반복적인 코드 사용이 필요 불가결한 것이다.
하지만 영속성 프레임워크는 다르다.
영속성 프레임워크를 활용하면 "DB와 Application" 연결에 대해 아예 신경 쓸 필요가 없다. 모든 중간 과정은 영속성 프레임워크측에서 해결해주며, 우리는 오직 영속성 프레임워크 측에서 제공하는 문법에 맞게 클래스만 재활용하면 바로 SQL 구문을 활용할 수 있게 해 준다.
영속성 프레임워크를 결국 데이터의 CRUD를 다루는 클래스 및 설정 파일들을 모아둔 것이며, JDBC와는 달리 간단한 작업으로 DB와 연동이 가능하고 애플리케이션에 SQL 구문 적용이 간편하며 안정적인 구동을 가능하게 해 주기 때문에 많이 활용되는 프레임워크가 되었다.
객체를 통해 간접적으로 데이터베이서를 다루는 영속성 프레임워크이다.
ORM에서는 객체와 데이터베이스를 자동 매핑하여 어떤 멤버 변수가 어떤 SQL Table에 들어가는지에 대한 고민이 필요 없다.(ORM 측에서 자동으로 멤버 변수를 규칙에 맞게 Column 명으로 변환함)
객체와 RDBMS를 매핑하여 "테이블을 객체지향적으로 활용한다"라는 점에서 객체 지향적인 개발의 끝을 달리는 기술이라고 해도 손색이 없는 것 같다
또한 ORM을 활용했을 때 키워드를 활용하면 SQL 구문 없이도 직관적으로 테이블 내의 데이터를 처리할 수 있다는 장점도 가진다. 따라서 이론상으로는 SQL 구문을 모르더라도 ORM만 활용할 수 있으면 RDBMS 데이터를 자유자재로 다룰 수 있게 되는 것이다.
예를 들어 JPA에서는 "LessThan" 키워드를 통해 특정 값보다 작은 항목을 탐색할 수도 있고, IsNull 키워드를 통해 nulll인 항목을 탐색할 수도 있는 등 여러 가지 키워드를 통해 SQL 구문을 대체할 수 있게 된다.
ORM은 대표적으로 Hibernate, JPA가 존재한다
SQL 문장으로 직접 데이터베이스의 데이터를 다루는 영속성 프레임워크이다.
ORM은 "객체와 테이블"을 매핑했다면 SQL Mapper는 "객체와 SQL 구문"을 매핑하는 기술이다.
SQL Mapper는 결국 ORM과 성질 자체가 다르므로 완벽히 다른 기술이지만 영속성 프레임워크라는 큰 범주에 묶여 있기도 해서 많이 비교되고 있다.
(실제로 MyBatis와 JPA의 사용 비율 비교에 대한 글이 많이 게시된 것을 알 수 있다)
ORM과 달리 SQL Mapper는 SQL과 객체를 매핑시켜주기 때문에 무조건 SQL 구문을 알아야지만 활용할 수 있다. 하지만 SQL 구문을 직접 적용할 수 있기 때문에 DB에 대해 잘 아는 전문가라면 자신이 원하는 순서로 데이터에 접근할 수 있도록 설정이 가능하다. 따라서 ORM보다 성능 예측이 쉬워질 것이다.
SQL Mapper는 대표적으로 MyBatis가 존재한다
단점은 딱 1가지이다.
"전문가가 활용하지 않으면 오히려 성능이 떨어진다"
영속성 프레임워크는 위에서 말했듯 미리 만들어져 있는 클래스를 재활용하여 DB와의 연동을 쉽게 하는 것이다. 즉, 원래 클래스에 대한 이해가 바탕이 되어야 개발을 쉽게 하면서 좋은 성능을 보일 수 있는 것이다.
이런 부분은 ORM에서 특히 자주 보인다. 나중에도 설명하겠지만 대규모 프로젝트 같은 경우에는 ORM과 SQL Mapper를 같이 활용하는데 이는 ORM의 편리성 때문이다.
ORM은 편리하게 활용할 수는 있으나 반대로 말하자면 개발자가 아닌 프레임워크 측에서 알아서 SQL 구문을 생성한 이후 로직을 작동시킨다. 즉, 설계를 매우 신중히 해야지만 제대로 활용할 수 있다는 점이다. 만약 설계를 제대로 하지 않으면 1 ~ 2단계를 더 거쳐 SQL 결과를 낼 수도 있고, 이런 사소한 차이는 큰 성능 차이를 만들 수도 있다.
ORM과 SQL Mapper를 같이 활용하게 되면 이 단점을 많이 줄일 수는 있다. ORM에서 많은 로직을 처리하고, 동작이 조금 복잡한 Query 같은 경우 SQL Mapper를 활용해 "직접 SQL 구문을 입력함으로써" 중간 단계를 지정해줌으로써 ORM의 단점을 줄이는 것이다.
결국 ORM과 SQL Mapper를 둘 다 활용할 수 있어야 좋은 성능을 볼 수 있다는 점에서 전문가의 필요성은 더욱 커지게 되며, 쉽게 활용하기 위해 만들어진 프레임워크를 제대로 사용하기 위해서는 프레임워크의 전문가가 되어야 한다는 이상하다면 이상할 수 있는 문제점이 생기게 되는 것이다.
(ORM과 SQL Mapper의 동시 사용 같은 경우는 나중에 제대로 설명하겠다)