첫째, SQL 안써도 됨
OOP와 RDB 간의 패러다임 불일치 때문에 생기는 여러 부작용 중에 하나가 SQL을 앱에서 직접 써줘야 한다는 것이다. ORM은 클래스와 관계형 DB 테이블을 매핑해주는 접근 방식 혹은 프레임워크로서, 개발자 대신 SQL을 작성해주는 역할도 한다.
둘째, 객체의 정보가 온전히 유지됨
자바 앱은 OOP를 지향하므로, 처음부터 끝까지 현실 세계에 존재하는 객체처럼 데이터를 다룰 수 있어야 한다. 예를 들어서 "상품(Product)"이라는 부모를 가지는 "책(Book)"은 앱 내에서는 처음부터 끝까지 부모가 있는 객체로서 다루어져야 한다. 그러나 DB에서 Select를 할 때 개발자가 부모에 해당하는 데이터를 같이 select 해오지 않으면 해당 객체는 앱에서만큼은 부모가 없는 것처럼 보인다.
그러니까 개발자는 어떤 데이터까지 쓸 것인지 신경을 곤두세워서 프로그래밍을 해야 한다. 그러나 JPA에서는 Entity가 서로 상속관계임을 명시해주면 알아서 Insert해주고, 알아서 조인해서 Select 해준다. 개발자는 어디까지 select 해왔더라? 확인할 필요가 없다. ORM과 함께라면 JAVA 메모리에 단기 저장된 데이터도 더이상 피상적이지 않다. 현실에 존재하는 책을 다루듯이 그 책을 다룰 수 있다. 따라서 JPA는 RDB를 사용할 수밖에 없는 상황에서, 진정한 OOP로 가기 위한 JAVA의 노력 이라고 할 수 있다.
셋째, 객체 동등 비교가 가능해짐
DB에서는 동일한 객체를 총 2회 select 하여 Java 앱에서 각각 `myBook`과 `yourBook`으로 객체를 생성하면 별도의 hashCode와 equals 오버라이딩 없이는 myBook =/= yourBook이 된다. 이 또한 OOP와 RDB간에 패러다임 불일치가 존재한다는 것을 눈으로 가장 쉽게 확인할 수 있는 예이다. ORM은 객체를 현실세계의 객체처럼 다룰 수 있도록 동일한 객체인 경우 동등 비교 시 true를 반환하도록 미리 프로그래밍 되어있다. 역시 진정한 OOP로 가기 위한 노력중 하나이다.
'웹' 카테고리의 다른 글
AWS Code Deploy 사용법 (0) | 2024.11.30 |
---|---|
OSIV와 SSE (0) | 2024.10.29 |
OSIV는 안티패턴? (2) | 2024.10.28 |
OSIV(open-in-view)란? (feat. LazyInitializaionException) (0) | 2024.10.27 |
JAVA 앱 배포하기 (0) | 2020.07.28 |