휴지 상태 vs JPA vs JDO - 각각의 장단점
ORM은 개념으로 잘 알고 있으며, 몇 년 전에 nHibernate를 에 사용한 적도 있습니다.NET 프로젝트입니다만, Java에서의 ORM에 대한 토픽을 이해하지 못하고, 이러한 툴을 사용할 기회가 없었습니다.
그러나 이제 일련의 레거시 웹 서비스에서 벗어나기 위해 애플리케이션 중 하나에 ORM 도구를 사용할 수 있습니다.
JPA 사양의 차이, Hibernate 라이브러리 자체의 특징, JDO가 제공하는 기능을 구분하는 데 어려움을 겪고 있습니다.
이 질문이 좀 자유롭다는 것은 알지만, 저는 다음과 같은 의견을 듣고 싶습니다.
- 각각의 장점과 단점은 무엇인가요?
- 새로운 프로젝트에 어떤 것을 제안하시겠습니까?
- 어느 하나의 프레임워크와 다른 프레임워크를 사용하는 것이 타당한지에 대한 특정 조건이 있습니까?
주의사항:
- JDO와 JPA는 모두 구현이 아닌 사양입니다.
- 표준 JPA만을 사용하도록 코드를 제한하면 JPA 구현을 바꿀 수 있습니다(JDO의 경우도 마찬가지입니다).
- 휴지 상태는, 그러한 JPA 의 실장 중 하나로 사용할 수 있습니다.
- 그러나 Hibernate는 네이티브 API를 제공하며 JPA 이상의 기능을 제공합니다.
IMO, 동면기를 추천합니다.
휴지 상태 고유의 기능을 사용할 필요가 있는 경우 어떻게 해야 하는지에 대한 몇 가지 의견/질문이 있었습니다.여러 가지 견해가 있지만 조언은 다음과 같습니다.
벤더의 제휴가 염려되지 않는 경우는, Hibernate 와 그 외의 JPA 및 JDO 의 실장(다양한 벤더 고유의 확장 기능 포함)을 선택해 주세요.
벤더의 제휴가 염려되어 벤더 고유의 확장에 의존하지 않고 JPA를 사용할 수 없는 경우는, JPA를 사용하지 말아 주세요(JDO의 경우도 마찬가지).
실제로는 벤더와의 제휴에 대한 우려와 벤더 고유의 확장이 얼마나 필요한지 균형을 맞춰야 할 것입니다.
또, 각 테크놀로지에 대해 얼마나 잘 알고 있는지, 라이센싱에 드는 제품의 비용, JDO와 JPA의 장래에 대해 누구로부터 생각하고 있는지를 알 수 있습니다.
JDO의 DataNucleus 구현을 평가해야 합니다.Hibernate는 매우 인기 있는 것처럼 보였지만, 이것이 100% 투과적인 지속성 솔루션이 아니라는 것을 금방 깨달았기 때문에 우리는 Hibernate로 시작했습니다.주의사항이 너무 많고 문서에는 '이런 상황이 발생하면 코드를 이렇게 써야 한다'는 내용이 가득하여 자유롭게 모델링하고 코딩할 수 있는 재미를 빼앗았습니다.JDO를 통해 코드나 모델을 '제대로 작동'하도록 조정한 적은 없습니다.단순한 POJO를 마치 '메모리'에서만 사용할 것처럼 디자인하고 코드화할 수 있지만 투명하게 지속할 수 있습니다.
최대 절전 모드보다 JDO/DataNucleus의 또 다른 장점은 실행 시간 리플렉션 오버헤드가 모두 있는 것은 아니며, 최대 프로젝트에서는 최대 절전 모드인 실행 시간 리플렉션 파워 프록시 패턴이 아닌 빌드 시간 바이트 코드 확장(아마도 빌드 시간에 1초 추가)을 사용하기 때문에 메모리 효율이 높다는 것입니다.
하이버네이트에 대해 또 다른 짜증나는 점은 당신이 그 물체로 생각하는 것에 대한 언급이 있다는 것이다.그것은 종종 그 물체에 대한 '추적'이다.바이트 코드 확장의 이점을 활용하지 않고 프록시 패턴은 온 디맨드 로드를 허용해야 합니다(즉, 최상위 개체를 가져올 때 전체 개체 그래프를 가져오지 않도록 합니다).참조하고 있는 오브젝트는 그 오브젝트의 프록시일 뿐이기 때문에 등호 및 해시 코드를 덮어쓸 준비를 합니다.
다음은 JDO에서는 얻을 수 없는 Hibernate에서 얻을 수 있는 좌절의 예입니다.
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
'해결책'으로 코딩하는 것을 좋아한다면, 물론, Hibernate가 당신을 위한 것입니다.모델링, 디자인 및 코딩에 모든 시간을 할애하고 추잡한 회피책을 마련하지 않는 깔끔하고 순수하며 객체 지향적인 개발에 만족한다면 JDO/DataNucleus를 평가하는 데 몇 시간을 할애해 보십시오.투자한 시간은 천 배의 보상을 받을 것이다.
2017년 2월 갱신
오랫동안 Data Nucleus는 JDO 지속성 표준과 더불어 JPA 지속성 표준을 구현하고 있기 때문에 기존 JPA 프로젝트를 Hibernate에서 Data Nucleus로 이식하는 것은 매우 간단해야 하며, 코드 변경은 거의 없지만 위의 Data Nucleus의 장점을 모두 얻을 수 있습니다.따라서 질문의 관점에서 JPA(RDBMS만)와 JDO(RDBMS + SQL 없음 + ODB) 중 하나를 선택합니다.MS + 기타) Data Nucleus는 둘 다 지원하며, 휴지 상태는 JPA로만 제한됩니다.
휴지 상태 DB 업데이트 성능
ORM을 선택할 때 고려해야 할 또 다른 문제는 더러운 체크 메커니즘의 효율성입니다.이것은 현재 트랜잭션에서 변경된 객체를 갱신하기 위해 SQL을 구축해야 할 때 특히 객체가 많을 때 매우 중요합니다.Hibernate의 더러운 체크 메커니즘에 대한 자세한 기술적 설명은 이 SO 답변에 있습니다: Hibernate 삽입이 매우 느린 JPA
최근에 Java 프로젝트의 지속성 프레임워크를 평가 및 선택했는데, 결과는 다음과 같습니다.
JDO에 대한 지원은 주로 다음과 같습니다.
- sql 이외의 데이터 소스, db4o, hbase, ldap, bigtable, couchdb(cassandra용 플러그인) 등을 사용할 수 있습니다.
- SQL에서 비 SQL 데이터 소스로 쉽게 전환하거나 데이터 소스를 반대로 전환할 수 있습니다.
- hashcode() 및 equals() 구현에 관해 프록시 오브젝트가 없기 때문에 문제가 적습니다.
- POJO가 증가하므로 필요한 회피책도 줄어듭니다.
- 더 많은 관계 및 필드 유형을 지원합니다.
JPA에 대한 지원은 주로 다음과 같습니다.
- 보다 인기 있는
- jdo는 죽었다.
- 바이트 코드 확장을 사용하지 않음
JDO/Datanucleus를 분명히 사용하지 않은 JPA 개발자들의 JDO를 사용하지 않는 것에 대한 설득력이 약한 게시물을 많이 볼 수 있습니다.
JDO로 이행한 JDO 유저로부터의 투고도 많아, 그 결과 매우 기뻐하고 있습니다.
JPA의 인기에 대해서는 기술적으로 우수하다기보다는 RDBMS 벤더의 서포트에 의한 것으로 생각됩니다.(저에게는 VHS/베타맥스라고 생각됩니다).
구글이 GA를 위해 JDO를 채택하고 소스 코드(http://sourceforge.net/projects/datanucleus/))를 적극적으로 개발하는 것에서 알 수 있듯이 JDO와 그 레퍼런스 구현 Datanucleus는 확실히 죽지 않았다.
바이트 코드 강화로 인해 JDO에 대한 여러 가지 불만이 제기되었지만, 왜 나쁜지에 대한 설명은 아직 없습니다.
사실 NoSQL 솔루션에 점점 더 집착하는 세상에서 JDO(및 데이터핵 구현)가 훨씬 더 안전한 선택인 것 같습니다.
JDO/Datanucleus를 사용하기 시작한 지 얼마 되지 않아 db4o와 mysql을 쉽게 전환할 수 있도록 셋업했습니다.db4o를 사용하면 DB 스키마에 대해 크게 걱정할 필요가 없으며, 스키마가 안정되어 데이터베이스에 배치되는 것이 빠른 개발에 도움이 됩니다.또한 나중에 애플리케이션의 전체/부분을 GA에 배포하거나 분산 스토리지를 활용하거나 리팩터링 없이 hbase/hadoop/cassandra의 맵을 줄일 수 있다고 확신합니다.
Datanucleus를 시작하기 위한 첫 번째 장애물은 조금 까다롭다는 것을 알았습니다.-데이터핵 웹사이트의 문서는 읽기 조금 어렵지만 튜토리얼은 제가 원하는 것만큼 쉽게 따라 할 수 없습니다.그러나 API와 매핑에 대한 자세한 문서는 초기 학습 곡선을 통과하면 매우 좋습니다.
정답은 당신이 무엇을 원하느냐에 달렸어요.보다 깔끔한 코드, 벤더 록인 없음, 보다 pojo 지향적인 nosql 옵션을 원합니다.
대부분의 다른 개발자/시프와 마찬가지로 따뜻하고 까다로운 느낌을 원한다면 JPA/hibernate를 선택하십시오.만약 당신이 당신의 분야에서 선두를 달리고 싶다면, JDO/Datanucleus를 시승하고 스스로 결정하세요.
새로운 프로젝트에 어떤 것을 제안하시겠습니까?
난 둘 다 추천하지 않을 거야!스프링 DAO 사용JdbcTemplate와 함께StoredProcedure,RowMapper그리고.RowCallbackHandler대신.
Hibernate를 사용한 개인적인 경험으로는 예기치 않은 캐스케이드 업데이트 동작과 같은 문제를 이해하고 디버깅하기 위해 끝없이 많은 시간을 할애하여 사전에 절약한 시간을 상쇄할 수 없습니다.
관계형 DB를 사용하는 경우 코드가 관련 DB에 가까울수록 제어력이 높아집니다.스프링의 DAO 레이어는 매핑 레이어를 미세하게 제어하면서 보일러 플레이트 코드가 필요하지 않습니다.또, Spring의 트랜잭션 레이어에 통합되어 있기 때문에, 코드에 침입하는 일 없이(물론, 이것은 Hibernate에서도 얻을 수 있습니다) 복잡한 트랜잭션 동작을 매우 간단하게 추가할 수 있습니다.
JDO가 정지했습니다.
사실 JDO는 죽지 않았으니 사실 확인 부탁드립니다.JDO 2.2는 2008년 10월에 출시되었으며 현재 개발 중입니다.
이것은 Apache 아래에서 공개적으로 개발되었습니다.JPA보다 많은 릴리스가 출시되었으며, ORM 사양은 JPA2가 제안하는 기능보다 아직 앞서 있습니다.
JDO는 JPA보다 고도의 기능을 갖추고 있습니다.http://db.apache.org/jdo/jdo_v_jpa.html 를 참조해 주세요.
JPA (5년 이상 된 KODO JDO 코드 베이스의 Apache로부터의 Open JPA 실장)를 사용하고 있습니다.IMHO가 스펙을 무시하라고 하는 사람은 당신에게 나쁜 조언을 하는 것입니다.나는 시간을 들였고 분명히 보상을 받았다.JDO 또는 JPA를 사용하면 최소한의 변경으로 벤더를 변경할 수 있습니다(JPA에는 옴 매핑이 있기 때문에 벤더를 변경하는 데 하루도 걸리지 않습니다).나처럼 100개 이상의 테이블이 있으면 이건 엄청 커요.또한 클러스터별 캐쉬 제거 기능을 통해 캐슁을 기본 제공하므로 모든 것이 좋습니다.SQL/Jdbc는 고성능 쿼리에 적합하지만 알고리즘과 데이터 입력 루틴을 쓰는 데는 투명 지속성이 훨씬 우수합니다.시스템 전체에 SQL 쿼리가 16개 정도밖에 없습니다(50k 이상의 코드 줄).
제가 직접 조사해 봤는데, 그 둘 사이에 뚜렷한 차이를 찾을 수가 없어요.가장 큰 선택은 어떤 구현에서 사용하느냐에 있다고 생각합니다.Data Nucleus 플랫폼은 데이터 스토어에 구애받지 않는 구현이기 때문에 저 자신도 생각해 왔습니다.
JDO가 죽었다고 말하는 사람은 누구나 아스트로터핑 FUD 망나니이고 그들은 그것을 알고 있다.
JDO는 잘 살아있다.이 사양은 훨씬 젊고 제약이 많은 JPA보다 더 강력하고 성숙하며 고급입니다.
If you want to limit yourself to only what's available in the JPA standard you can write to JPA and use DataNucleus as a high performance, more transparent persistence implementation than the other implementations of JPA. Of course DataNucleus also implements the JDO standard if you want the flexibility and efficiency of modeling that JDO brings.
I've used Hibernate (JPA implementation) and JPOX (JDO implementation) in the same project. JPOX worked ok, but ran into bugs fairly quickly, there where some Java 5 language features it did not support at the time. It had problems playing nice with XA transactions. I was generating the database schema from the JDO objects. It wanted to connect to a database every time which is annoying if your Oracle connection happens not be working.
We then switched to Hibernate. We toyed around with just using pure JPA for awhile, but we needed to use some of the Hibernate specific features to do the mapping. Running the same code on multiple databases is very easy. Hibernate seems to cache objects aggressively or just have strange caching behavior at times. There are a few DDL constructs Hibernate can not handle and so they are defined in an additional file that is run to initialize the database. When I've run into a Hibernate problem there are often many people that have run into the same problem which makes googling for solutions easier. Finally, Hibernate seems to be well designed and reliable.
Some other responders have suggested just using SQL. The real killer use case for object relational mapping is testing and development. The databases that are built to handle large volumes of data are typically expensive and or they are difficult to install. They are difficult to test with. There are plenty of in-memory Java databases that can be used to test with, but are typically useless for production. Being able to use a real, but limited database, will increase development productivity and code reliability.
I made a sample WebApp in May 2012 that uses JDO 3.0 & DataNucleus 3.0 - take a look how clean it is: https://github.com/TorbenVesterager/BadAssWebApp
Okay maybe it's a little bit too clean, because I use the POJOs both for the database and the JSON client, but it's fun :)
PS: Contains a few SuppressWarnings annotations (developed in IntelliJ 11)
ReferenceURL : https://stackoverflow.com/questions/530215/hibernate-vs-jpa-vs-jdo-pros-and-cons-of-each
'IT이야기' 카테고리의 다른 글
| 입력된 텍스트 필드의 아이콘에서 사용 가능을 클릭합니다. (0) | 2022.06.01 |
|---|---|
| Vuex 어레이에서 특정 항목 제거 (0) | 2022.06.01 |
| 왜 Mockito는 정적 방식을 조롱하지 않는 거죠? (0) | 2022.06.01 |
| Vuejs 3 - data() 및 setup() 이외의 후크에서 템플릿으로 데이터를 전송하는 방법 (0) | 2022.06.01 |
| 범위 지정 슬롯에서 refs 요소를 가져오는 방법 (0) | 2022.06.01 |