이와 같이 논의 할 때마다 중요한 것은 객체 관계 맵퍼 ( “ORM”)와 데이터베이스 추상화 계층 을 명확하게 구분하는 것 입니다. ORM은 일종의 데이터베이스 추상화 계층이지만 모든 데이터베이스 추상화 계층이 ORM 인 것은 아닙니다. 이것을 이해하기 위해 공부하는 좋은 도구 중 하나는 파이썬의 인기있는 SQLAlchemy 라이브러리입니다.이 라이브러리는 “SQL 툴킷 및 Object Relational Mapper”(내 볼드체)로 다른 것으로 생각합니다. 주요 기능 페이지 에 넣을 때 :

ORM이 필요하지 않습니다

SQLAlchemy는 Core 와 ORM . Core 자체는 완전한 기능을 갖춘 SQL 추상화 툴킷으로, 다양한 DBAPI 구현 및 동작에 대한 매끄러운 추상화 계층을 제공하며 생성 된 Python 표현식을 통해 SQL 언어를 표현할 수있는 SQL Expression Language도 제공합니다. DDL 문을 생성하고 기존 스키마를 검사 할 수있는 스키마 표현 시스템과 파이썬 유형을 데이터베이스 유형에 매핑 할 수있는 유형 시스템은 시스템을 반올림합니다. 그러면 Object Relational Mapper는 Core를 기반으로하는 선택적 패키지입니다.

프론트 페이지는 다음과 같이 ORM을 설명합니다.

SQLAlchemy는 데이터 맵퍼 패턴을 제공하는 선택적 구성 요소 인 ORM (Object-Relational Mapper)으로 가장 유명합니다. 여기서 클래스는 개방형으로 여러 가지 방법으로 데이터베이스에 맵핑 할 수 있습니다. 처음부터 깨끗하게 분리되었습니다.

ORM의 핵심 아이디어는 유명한 객체 관계형 임피던스 불일치 를 시도하고 연결하는 것 입니다. 이는 사용자 정의 클래스 와 데이터베이스 스키마의 테이블 간 관계를 정의 하고 애플리케이션 클래스에 대한 자동 “저장”및 “로드”조작을 제공함을 의미합니다.

반대로, 비 ORM 데이터베이스 추상화 계층은 관계 지향 데이터 모델과 SQL에 더 헌신적 인 경향이 있으며, 객체 지향에는 전혀 영향을 미치지 않습니다. 따라서 테이블과 클래스 사이에 “매핑 (mapping)”기능을 제공하고 프로그래머로부터 데이터베이스 스키마를 숨기는 대신 데이터베이스를 프로그래머 에게 노출 시키는 경향이 있지만 API와 추상화는 더 좋습니다. 예를 들어, SQL 쿼리 빌더를 사용하면 다음과 같이 문자열 조작없이 프로그래밍 방식으로 복잡한 SQL 쿼리를 생성 할 수 있습니다 ( Java 용 jOOQ 라이브러리의 예 ).

// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
    create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
          .from(BOOK)
          .join(AUTHOR)
          .on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
          .where(BOOK.PUBLISHED_IN.equal(1948))
          .fetch();

지금, Play 프레임 워크는 방금 설명한 것과 100 % 리그가 아닌 것처럼 보이지만 그 논쟁은이 일반적인 공간에있는 것처럼 보입니다. 관계형 모델을 클래스로 변환하고 다시 변환하는 대신 직접 작업하십시오.

jOOQ 라이브러리 으로 ORMs에 대위법으로 연구 가치가있다. 또한 읽을 가치가있는 관련 블로그 항목이 있습니다.

• http://blog.jooq.org/2015/03/24/jooq-vs-hibernate-when-to-choose-which/
• http://blog.jooq.org/2014/04/11/java-8-friday-no-more-need-for-orms/

답변