[sql] ORM 또는 일반 SQL을 사용하십니까? [닫은]

Hibernate, EclipseLink, Toplink, OpenJPA 등을 포함하여 JPA (Java Persistence API, 기본적으로 Java / J2EE / EJB에 대한 표준화 된 ORM API)를 다루는 데 상당한 시간을 소비 한 사람으로서 관찰.

1. ORM은 빠르지 않습니다. 그것들은 적절할 수 있고 대부분의 시간은 적당하지만 대량의 대기 시간이 짧은 환경에서는 그렇지 않습니다.
2. Java 및 C #과 같은 범용 프로그래밍 언어에서는 작동하기 위해 엄청나게 많은 마법이 필요합니다 (예 : Java에서로드 타임 제직, 계측 등).
3. ORM을 사용할 때 (의도적 인 것처럼 보이는) SQL에서 멀어지기보다는 ORM이 성능있는 SQL을 생성하도록 XML 및 / 또는 주석 / 속성을 조정하는 데 얼마나 많은 시간이 걸리는지 놀라게 될 것입니다.
4. 복잡한 쿼리의 경우 실제로 대체 방법이 없습니다. JPA와 마찬가지로 원시 SQL에서는 불가능한 일부 쿼리가 있으며 JPA에서 원시 SQL을 사용해야 할 때 (C # /. Net에는 동적 유형-var가 있습니다.) Object 배열보다 좋습니다);
5. ORM을 사용할 때 엄청나게 많은 “gotchas”가 있습니다. 여기에는 의도하지 않았거나 예기치 않은 동작, JPA 또는 이와 유사한 메소드에서 refresh ()를 사용하여 데이터베이스에 대한 SQL 업데이트를 수행 할 수있는 기능을 빌드해야한다는 사실이 포함됩니다. JPA는 기본적으로 모든 것을 캐시하므로 직접 데이터베이스를 포착하지 않습니다. 업데이트-직접 SQL 업데이트를 실행하는 것이 일반적인 프로덕션 지원 활동입니다).
6. 객체 관계 불일치는 항상 문제를 일으킬 것입니다. 이러한 문제로 인해 추상화의 복잡성과 완전성 사이에 상충 관계가 있습니다. 때때로 나는 JPA가 너무 멀리 가고 추상화가 복잡성 히트가 정당화되지 않은 실제 수익률 감소 법칙에 부딪쳤다 고 느꼈다.

좀 더 설명이 필요한 또 다른 문제가 있습니다.

웹 응용 프로그램의 전통적인 모델은 지속성 계층과 프레젠테이션 계층을 갖는 것입니다 (서비스 또는 다른 계층 사이에있을 수 있지만이 논의에서 중요한 두 가지입니다). ORM은 퍼시스턴스 레이어에서 프리젠 테이션 레이어 (즉, 엔티티)까지 견고하게 보여줍니다.

보다 원시적 인 SQL 메소드에 대한 비판 중 하나는 단순히 하나의 쿼리에서 사용되는 이러한 모든 VO (값 오브젝트) 또는 DTO (데이터 전송 오브젝트)로 끝나는 것입니다. 이를 없애기 때문에 ORM의 장점으로 선전됩니다.

문제는 ORM에서 사라지지 않는 문제이며 단순히 프리젠 테이션 레이어로 넘어갑니다. 쿼리에 대한 VO / DTO를 만드는 대신 일반적으로 모든보기마다 하나씩 사용자 지정 프레젠테이션 개체를 만듭니다. 이것이 어떻게 더 낫습니까? 그렇지 않다.

ORM 또는 SQL로 이것에 대해 썼습니다 : 아직 있습니까? .

요즘 내 선택 기술 (자바)은 이바 티스입니다. JPA가 할 수있는 것의 90 % 이상을 수행하는 SQL 주위의 꽤 얇은 래퍼입니다 (문서화되지는 않았지만 관계의 지연 로딩을 수행 할 수도 있음).하지만 복잡성과 실제 코드 측면에서 오버 헤드가 훨씬 적습니다.

이것은 작년에 내가 작성한 GWT 응용 프로그램에서 나왔습니다. 서비스 구현에서 EclipseLink에서 프리젠 테이션 오브젝트로의 많은 변환 우리가 ibatis를 사용한다면, ibatis로 적절한 객체를 생성 한 다음 스택 위아래로 전달하는 것이 훨씬 간단했을 것입니다. 일부 순수 주의자들은 이것이 Bad ™라고 주장 할 수 있습니다. 어쩌면 (이론적으로) 어쨌든 나는 당신에게 무엇을 말해줍니다 : 그것은 더 간단한 코드, 더 간단한 스택 및 더 많은 생산성으로 이어질 것입니다.

답변