어떤 Java ORM을 선호합니까? 그 이유는 무엇입니까? [닫은]

꽤 개방 된 질문입니다. 새 프로젝트를 시작하고 데이터베이스 액세스와 통합하기 위해 다른 ORM을 찾고 있습니다.

즐겨 찾기가 있습니까? 깨끗하게 유지하는 것이 좋습니까?

ORM 사용을 중단했습니다.

그 이유는 개념에 큰 결함이 아닙니다. 최대 절전 모드가 잘 작동합니다. 대신 쿼리의 오버 헤드가 적고 많은 복잡한 논리를 큰 SQL 쿼리에 맞추고 많은 처리를 데이터베이스로 옮길 수 있습니다.

따라서 JDBC 패키지 만 사용하십시오.

ORM을 갖는 것은 적은 이점으로 너무 많은 제어권을 빼앗기기 때문에 불가능합니다. ORM 사용으로 인한 이상을 디버그해야 할 때 절약되는 시간이 쉽게 사라집니다. 또한 ORM은 개발자가 SQL을 배우지 않고 관계형 데이터베이스가 작동하는 방식과이를 활용하여 이점을 얻지 못하게합니다.

많은 ORM이 훌륭합니다. JDBC 위에 추상화를 추가하려는 이유를 알아야합니다. 나는 당신 에게 http://www.jooq.org 를 추천 할 수 있습니다 (면책 조항 : 나는 jOOQ의 제작자 이므로이 대답은 편견입니다). jOOQ는 다음과 같은 패러다임을 수용합니다.

• SQL은 좋은 것입니다. 많은 것들이 SQL로 아주 잘 표현 될 수 있습니다. SQL의 완전한 추상화가 필요하지 않습니다.
• 관계형 데이터 모델은 좋은 것입니다. 지난 40 년간 최고의 데이터 모델로 입증되었습니다. XML 데이터베이스 나 진정한 객체 지향 데이터 모델이 필요하지 않습니다. 대신, 회사는 Oracle, MySQL, MSSQL, DB2 또는 기타 RDBMS의 여러 인스턴스를 실행합니다.
• SQL에는 구조와 구문이 있습니다. JDBC에서 "낮은 수준의"문자열 연결을 사용하거나 HQL에서 "높은 수준의"문자열 연결을 사용하여 표현하면 안됩니다. 둘 다 구문 오류가 발생하기 쉽습니다.
• 변수 쿼리는 주요 쿼리를 처리 할 때 매우 복잡한 경향이 있습니다. 그것은 추상화되어야 할 것입니다.
• POJO는 데이터베이스 데이터를 조작하는 Java 코드를 작성할 때 유용합니다.
• POJO는 수동으로 작성하고 유지하는 데 어려움이 있습니다. 코드 생성은 갈 길입니다. datatype-safety를 포함한 컴파일 안전 쿼리가 있습니다.
• 데이터베이스가 우선입니다. 데이터베이스 위에있는 응용 프로그램은 시간이지나면서 변경 될 수 있지만 데이터베이스 자체는 더 오래 지속될 수 있습니다.
• 예, 레거시 데이터베이스에 저장 프로 시저 및 사용자 정의 형식 (UDT)이 있습니다. 데이터베이스 도구가이를 지원해야합니다.

다른 좋은 ORM이 많이 있습니다. 특히 최대 절전 모드 또는 iBATIS에는 훌륭한 커뮤니티가 있습니다. 그러나 직관적이고 간단한 것을 찾고 있다면 jOOQ를 사용해보십시오. 당신은 그것을 사랑합니다! :-)

이 SQL 예를 확인하십시오.

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

그리고 그것을 jOOQ로 표현할 수있는 방법 :

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

최대 절전 모드는 기본적으로 Java의 사실상 표준이며 JPA 생성의 원동력 중 하나이기 때문입니다. Spring에서 탁월한 지원을 받고 있으며 거의 ​​모든 Java 프레임 워크가이를 지원합니다. 마지막으로 GORM은 Groovy를 사용하여 동적 파인더 등을 수행하는 멋진 래퍼입니다.

심지어 .NET (NHibernate)으로 포팅되었으므로 거기에서도 사용할 수 있습니다.

최대 절전 모드 :

• 안정되어 있습니다-수년간 주변에 있었고 큰 문제가 없습니다.
• ORM 필드의 표준을 나타냅니다
• 지시 할뿐만 아니라 표준 (JPA)을 구현합니다.
• 인터넷에 관한 많은 정보가 있습니다. 많은 튜토리얼, 일반적인 문제 해결 방법 등이 있습니다
• 강력합니다. 매우 복잡한 객체 모델을 관계형 모델로 변환 할 수 있습니다.
• 그것은 모든 주요 및 중간 RDBMS를 지원합니다
• 일단 배우면 쉽게 작업 할 수 있습니다

ORM을 사용하는 이유와시기에 대한 몇 가지 사항 :

• 시스템의 오브젝트를 사용하여 작업합니다 (시스템이 올바르게 설계된 경우). JDBC를 사용하더라도 변환 계층을 만들어 데이터를 객체로 전송할 수 있습니다. 그러나 내 베팅은 모든 맞춤형 솔루션보다 최대 절전 모드가 번역에서 더 낫다는 것입니다.
• 그것은 통제력을 박탈하지 않습니다. 아주 작은 세부 사항으로 사물을 제어 할 수 있으며 API에 원격 기능이없는 경우 기본 쿼리를 실행하면됩니다.
• 중간 규모 이상의 시스템에서는 유지 관리가 가능할 경우 1 톤의 쿼리 (한 곳에 있거나 분산되어 있음)를 감당할 수 없습니다.
• 성능이 중요하지 않은 경우. 최대 절전 모드는 성능 오버 헤드를 추가하여 일부 경우 무시할 수 없습니다.

MyBatis 사용을 권장 합니다. JDBC 위에 얇은 계층으로, 오브젝트를 테이블에 맵핑하고 여전히 일반 SQL을 사용하는 것이 매우 쉽고 모든 것이 제어됩니다.

중간 크기의 JavaSE 애플리케이션을 작성할 때 Avaje Ebean에 대한 경험이 정말 좋았습니다 .

표준 JPA 주석을 사용하여 엔티티를 정의하지만 훨씬 더 간단한 API (No EntityManager 또는 첨부 / 분리 된 엔티티 쓰레기 없음)를 노출합니다. 또한 필요할 때 SQL 쿼리 또는 이벤트 일반 JDBC 호출을 쉽게 사용할 수 있습니다.

또한 쿼리를위한 매우 유동적이고 형식이 안전한 API가 있습니다. 다음과 같이 쓸 수 있습니다.

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

간단하고 마술이 아니기 때문에 SimpleORM . 모든 메타 데이터 구조를 Java 코드로 정의하며 매우 유연합니다.

SimpleORM은 관계형 데이터베이스의 데이터를 메모리의 Java 객체에 매핑하여 최대 절전 모드와 유사한 기능을 제공합니다. 조회는 Java 오브젝트로 지정 될 수 있으며, 오브젝트 ID는 데이터베이스 키와 정렬되며, 오브젝트 간의 관계는 유지되며 수정 된 오브젝트는 자동으로 낙관적 잠금으로 데이터베이스에 플러시됩니다.

그러나 최대 절전 모드와 달리 SimpleORM은 복잡한 구문 분석, 바이트 코드 처리 등을 필요로하지 않는 매우 간단한 객체 구조 및 아키텍처를 사용합니다. SimpleORM은 작고 투명하며 크기가 79K 및 52K 인 두 개의 항아리에 하나의 작고 선택적인 패키지가 있습니다. 의존성 (Slf4j). (최대 절전 모드는 2400K 이상이고 약 2000K의 종속 Jar에 해당합니다.) 이는 SimpleORM을 이해하기 쉽고 기술 위험을 크게 줄입니다.

Eclipse Link 는 여러 가지 이유로, 그러나 다른 메인 스트림 솔루션보다 덜 부풀어 오른 것처럼 느낍니다 (적어도 얼굴에 부풀어 오른 느낌).

오, 이클립스 링크는 JPA 2.0에 대한 참조 구현으로 선택되었습니다

자유 형식 SQL 쿼리의 Java 대체에 대한 우려 사항을 공유하는 동안 ORM을 비판하는 사람들은 일반적으로 응용 프로그램 디자인이 좋지 않기 때문에 그렇게하고 있다고 생각합니다.

True OOD는 클래스와 관계에 의해 주도되며 ORM은 다양한 관계 유형과 개체에 대한 일관된 매핑을 제공합니다. ORM 도구를 사용하고 ORM 프레임 워크가 지원하는 모든 쿼리 언어 (Java 표현식 트리, 쿼리 메소드, OQL 등을 포함하지만 이에 국한되지 않음)로 쿼리 쿼리 코딩을 끝내면 클래스 모델과 같은 무언가 잘못되고있는 것입니다. 대부분의 방식으로 요구 사항을 지원하지 않습니다. 깨끗한 응용 프로그램 디자인에는 실제로 응용 프로그램 수준에서 쿼리가 필요하지 않습니다. 사람들이 코드에 SQL 문자열 상수를 포함하는 데 사용 된 것과 같은 방식으로 ORM 프레임 워크를 사용하기 시작한 많은 프로젝트를 리팩토링했습니다. 결국 모든 사람이 일단 일치하면 전체 응용 프로그램이 얼마나 간단하고 유지 관리 가능한지에 대해 놀랐습니다. 사용 모델로 수업 모델을 구성하십시오. 검색 기능 등의 경우 쿼리 언어가 필요하지만 쿼리가 너무 제한되어있어 복잡한 VIEW를 작성하고 읽기 전용 영구 클래스에 매핑하는 것이 표현식을 작성하는 것보다 유지 관리하고 보는 것이 훨씬 좋습니다. 응용 프로그램 코드의 일부 쿼리 언어로. VIEW 접근법은 또한 데이터베이스 기능을 활용하며 구체화를 통해 Java 소스에있는 수기 SQL보다 성능면에서 훨씬 우수합니다. 따라서 사소한 응용 프로그램이 ORM을 사용하지 않는 이유는 없습니다. 그러나 쿼리조차도 너무 제한되어있어 복잡한 VIEW를 만들고 읽기 전용 영구 클래스에 매핑하는 것이 응용 프로그램 코드에서 일부 쿼리 언어로 식을 작성하는 것보다 유지 관리하고 보는 것이 훨씬 좋습니다. VIEW 접근법은 또한 데이터베이스 기능을 활용하며 구체화를 통해 Java 소스에있는 수기 SQL보다 성능면에서 훨씬 우수합니다. 따라서 사소한 응용 프로그램이 ORM을 사용하지 않는 이유는 없습니다. 그러나 쿼리조차도 너무 제한되어있어 복잡한 VIEW를 만들고 읽기 전용 영구 클래스에 매핑하는 것이 응용 프로그램 코드에서 일부 쿼리 언어로 식을 작성하는 것보다 유지 관리하고 보는 것이 훨씬 좋습니다. VIEW 접근법은 또한 데이터베이스 기능을 활용하며 구체화를 통해 Java 소스에있는 수기 SQL보다 성능면에서 훨씬 우수합니다. 따라서 사소한 응용 프로그램이 ORM을 사용하지 않는 이유는 없습니다.