Hibernate, iBatis, Java EE 또는 기타 Java ORM 도구

Hibernate, iBatis, Java EE 또는 기타 Java ORM 도구

---

우리는 대규모 엔터프라이즈 응용 프로그램을 계획하는 중입니다. 우리는 J2EE의 고통을 경험 한 후 최대 절전 모드를 평가하는 데 집중하고 있습니다.

새로운 Java EE API가 더 간단 해 보입니다. 또한 Hibernate와 iBatis에 대한 몇 가지 좋은 점을 읽었습니다. 우리 팀은 프레임 워크에 대한 경험이 거의 없습니다.

내가 결정하고 싶은 5 가지 주요 비교 포인트가 있습니다.

• 학습 곡선 / 사용 용이성
• 생산력
• 유지 보수성 / 안정성
• 성능 / 확장 성
• 손쉬운 문제 해결

J2EE 경험이있는 6 명 이하의 개발자 팀을 관리하는 경우 어떤 ORM 도구를 사용하고 그 이유는 무엇입니까?

---

이것에 대한 균열을 가져 보겠습니다. 먼저, Using an ORM or plain SQL? 에서이 주제에 대해 글을 썼습니다 . . 특히 귀하의 요점을 해결하기 위해 :

학습 곡선 / 사용 용이성

Ibatis는 SQL에 관한 것입니다. SQL을 알고 있다면 ibatis의 학습 곡선은 사소합니다. Ibatis는 SQL 위에서 다음과 같은 작업을 수행합니다.

• 그룹화
• 차별 유형; 과
• 동적 SQL.

여전히 배워야하지만 가장 큰 장애물은 SQL입니다.

반면에 JPA (Hibernate 포함)는 SQL과 거리를두고 관계형 방식이 아닌 객체로 사물을 표시하려고합니다. 그러나 Joel이 지적했듯이 추상화는 누출 되고 JPA도 예외는 아닙니다. JPA를 수행하려면 관계형 모델, SQL, 쿼리 성능 튜닝 등에 대해 알아야합니다.

Ibatis는 사용자가 알고 있거나 배우고있는 SQL을 단순히 적용하도록하는 반면, JPA는 구성 방법 (XML 또는 주석)을 알아야합니다. 이것은 외래 키 관계가 어떤 종류의 관계 (일대일, 일대 다 또는 다 대다), 유형 매핑 등임을 알아내는 것을 의미합니다.

SQL을 알고 있다면 JPA 학습의 장벽이 실제로 더 높다고 말할 것입니다. 그렇지 않은 경우 JPA와 혼합 된 결과로 인해 SQL 학습을 한동안 효과적으로 연기 할 수 있습니다 (그러나 무기한으로 미루지는 않습니다).

JPA를 사용하면 엔티티와 해당 관계를 설정하면 다른 개발자가이를 사용하기 만하면 JPA 구성에 대한 모든 것을 배울 필요가 없습니다. 이것은 이점이 될 수 있지만 개발자는 여전히 엔티티 관리자, 트랜잭션 관리, 관리 대상 개체와 관리되지 않는 개체 등에 대해 알아야합니다.

JPA에도 자체 쿼리 언어 (JPA-SQL)가 있으므로 SQL을 알고 있는지 여부를 알아야합니다. JPA-SQL이 SQL이 할 수있는 일을 할 수없는 상황을 발견하게 될 것입니다.

생산력

이것은 판단하기 어려운 것입니다. 개인적으로 저는 ibatis에서 더 생산적이라고 생각하지만 SQL에도 정말 익숙합니다. 일부는 Hibernate에서 훨씬 더 생산적이라고 주장 할 것이지만 이것은 아마도 부분적으로는 SQL에 익숙하지 않기 때문일 것입니다.

또한 JPA의 생산성은 기만적입니다. 데이터 모델이나 쿼리에 문제가 발생하기 때문에 로깅을 켜고 JPA 공급자가 생성 한 SQL을 확인한 다음 작업하는 동안 해결하는 데 반나절이 걸리는 쿼리가 발생하기 때문입니다. 설정과 호출의 조합을 제거하여 정확하고 성능이 뛰어난 무언가를 생성합니다.

SQL을 직접 작성했기 때문에 Ibatis에서는 이런 종류의 문제가 없습니다. PL / SQL Developer, SQL Server Management Studio, Navicat for MySQL 등에서 SQL을 실행하여 테스트합니다. 쿼리가 옳다면 입력과 출력을 매핑하기 만하면됩니다.

또한 JPA-QL이 순수한 SQL보다 어색하다는 것을 알았습니다. 결과를보기 위해 JPA-QL 쿼리를 실행하기위한 별도의 도구가 필요하며 더 많은 것을 배워야합니다. 나는 실제로 JPA의 전체 부분을 일부 사람들이 좋아하지만 다소 어색하고 다루기 힘들다는 것을 알았습니다.

유지 보수성 / 안정성

여기서 Ibatis의 위험은 확산입니다. 즉, 개발 팀은 재사용을 찾지 않고 필요에 따라 값 객체와 쿼리를 계속 추가 할 수 있지만 JPA는 테이블 당 하나의 entitty를 가지고 있으며 일단 해당 엔티티를 가지면 그뿐입니다. 명명 된 쿼리는 해당 엔터티로 이동하는 경향이 있으므로 놓치기 어렵습니다. 임시 쿼리는 여전히 반복 될 수 있지만 잠재적 인 문제는 적다고 생각합니다.

그러나 그것은 강성의 희생이 따릅니다. 종종 응용 프로그램에서 다른 테이블의 데이터 조각이 필요합니다. SQL을 사용하면 단일 쿼리 (또는 적은 수의 쿼리)를 작성하여 모든 데이터를 한 번의 히트로 가져와 해당 목적을위한 사용자 지정 값 개체에 넣을 수 있기 때문에 쉽습니다.

JPA를 사용하면 해당 논리를 비즈니스 계층으로 이동합니다. 엔티티는 기본적으로 전부 또는 전혀 없습니다. 이제 그것은 엄격하게 사실이 아닙니다. 다양한 JPA 공급자를 사용하여 엔티티를 부분적으로로드하는 등의 작업을 수행 할 수 있지만 거기에서도 동일한 개별 엔티티에 대해 이야기하고 있습니다. 4 개의 테이블에서 데이터가 필요한 경우 4 개의 엔터티가 필요하거나 원하는 데이터를 비즈니스 또는 프레젠테이션 계층에서 일종의 사용자 지정 값 개체로 결합해야합니다.

ibatis에 대해 내가 좋아하는 또 다른 점은 모든 SQL이 외부 (XML 파일)라는 것입니다. 어떤 사람들은 이것이 단점이라고 언급하지만 나는 그렇지 않습니다. 그런 다음 XML 파일을 검색하여 테이블 및 / 또는 열의 사용을 비교적 쉽게 찾을 수 있습니다. 코드에 SQL이 삽입되어 있으면 (또는 SQL이 전혀없는 경우) 찾기가 훨씬 더 어려울 수 있습니다. SQL을 잘라내어 데이터베이스 도구에 붙여넣고 실행할 수도 있습니다. 나는 이것이 몇 년 동안 나에게 얼마나 유용했는지 충분히 과장 할 수 없습니다.

성능 / 확장 성

여기서는 ibatis가 승리한다고 생각합니다. 바로 SQL이고 저렴한 비용입니다. 본질적으로 JPA는 동일한 수준의 대기 시간 또는 처리량을 관리 할 수 ​​없습니다. 이제 JPA는 대기 시간과 처리량이 거의 문제가되지 않는다는 것입니다. 그러나 고성능 시스템은 존재하며 JPA와 같은 더 무거운 솔루션을 선호하지 않는 경향이 있습니다.

또한 ibatis를 사용하면 필요한 정확한 열과 함께 원하는 데이터를 정확하게 반환하는 쿼리를 작성할 수 있습니다. 근본적으로 JPA가 개별 엔티티를 반환 할 때이를 이길 수있는 방법은 없습니다.

손쉬운 문제 해결

나는 이것이 Ibatis에게도 승리라고 생각합니다. 위에서 언급했듯이 JPA를 사용하면 쿼리 또는 엔티티가 원하는 SQL을 생성하거나 엔티티 관리자가 관리되지 않는 객체 (배치의 일부일 수 있음)를 유지하려고했기 때문에 트랜잭션이 실패하는 문제를 진단하는 데 반나절을 소비 할 수 있습니다. 많은 일을했기 때문에 찾기가 쉽지 않을 수 있습니다.)

존재하지 않는 테이블이나 열을 사용하려고하면 둘 다 실패합니다.

기타 기준

이제 요구 사항 중 하나로 이식성을 언급하지 않았습니다 (데이터베이스 공급 업체 간 이동). 여기서 JPA가 장점이 있다는 점은 주목할 가치가 있습니다. 주석은 예를 들어 Hibernate XML보다 이식성이 낮지 만 (예를 들어 표준 JPA 주석은 Hibernate의 "네이티브"ID 유형에 상응하는 것이 없습니다) 둘 다 ibatis / SQL보다 이식성이 높습니다.

또한 JPA / Hibernate가 휴대용 DDL의 한 형태로 사용되는 것을 보았습니다. 즉, JPA 구성에서 데이터베이스 스키마를 생성하는 작은 Java 프로그램을 실행한다는 의미입니다. ibatis를 사용하면 지원되는 각 데이터베이스에 대한 스크립트가 필요합니다.

이식성의 단점은 JPA가 어떤면에서 가장 낮은 공통 분모라는 것입니다. 즉, 지원되는 동작은 광범위한 데이터베이스 공급 업체에서 일반적으로 지원되는 동작입니다. ibatis에서 Oracle Analytics를 사용하고 싶다면 문제 없습니다. JPA에서? 음, 그게 문제입니다.

---

iBatis와 Hibernate 간의 단순한 경험 법칙은 더 많은 SQL / 관계형 세계관을 원한다면 iBatis가 더 적합하다는 것입니다. 더 복잡한 상속 체인과 SQL에 대한 덜 직접적인 뷰의 경우 Hibernate. 둘 다 널리 사용되는 견고한 프레임 워크입니다. 그래서 나는 둘 다 잘 작동 할 것이라고 생각합니다. 둘 다에 대한 튜토리얼을 읽고 하나가 다른 것보다 더 좋은지 확인한 다음 하나를 선택하십시오.

나열한 것 중에서 성능이 크게 다르지 않다고 생각합니다. 병목 현상은 거의 변함없이 프레임 워크가 아닌 데이터베이스입니다. 다른 것들에 대해서는 다른 개발자들이 둘 중 하나를 선호 할 것이라고 생각합니다. 즉, 일반적으로 허용되는 우선 순위가 없습니다 (iBatis 대 Hibernate의 경우).

---

사용하는 솔루션은 Java EE 사양을 준수하도록 선택 (또는 필수)하는 방식에 따라 다릅니다. JPA는 Java EE 시스템에서 데이터 액세스를위한 "표준"이므로이를 준수하는 데 특별한 경우에는이를 사용해야합니다 (일부주의 사항 포함).

JPA는 객체 관계형 매핑 시스템의 표준화입니다. 따라서 구현을 제공하지 않고 단순히 표준화 된 접근 방식을 정의합니다. Hibernate Entity Manager는 그러한 구현 중 하나입니다.

Since JPA is a standard across multiple vendors and since it is still fairly new, it lacks some more esoteric functionality that is valuable in some use cases (for example, a Criteria API for generating dynamic SQL). If you go with JPA plan on situations where you'll nee to use Hibernate directly, or even JDBC directly. For situations such as this, a generic DAO pattern is very useful; you can modify this one: Generic Data Access Objects for use in JPA & JDBC quite easily.

JPA has some difficult restrictions (particularly if you're used to Hibernate), and imposes certain approaches on you that are difficult for developers who are more used to writing straight JDBC. If you are championing this as an approach, be sure to do your homework about the pros vs. cons of ORM vs. JDBC.

If you go with JPA, once you've reached the learning curve it will pay off in terms of simple development (particularly if you properly implement the abovementioned DAO pattern), but also in getting multi-tiered caching of query results. If done properly (a big "if", I know), I have seen this provide handsome benefits.

Lastly, if you have a legacy data model that you have little flexibility with, Hibernate (and JPA) will give you more headaches than maybe worth. For example:

• If the database does not have candidate primary keys (for effective hashCode & equals implementations) you will need to do upfront analysis on which columns define a row uniquely -- maybe simple, maybe complex depending on the complexity of your schema;
• If you're unable to add version or timestamp columns, you lose Hibernate's ability to do optimistic locking, and end up having to query before updating.

(Added in response to first comment) If you're lucky enough to re-design your database, two very important considerations if you're going to be using an ORM:

• Add a version number column to all relevant tables to support optimistic locking.
• During your data analysis, decide on non-nullable "alternate key" column(s) that developers should use for hashCode() & equals(). Don't use PK columns in those methods.

---

To add another option to the list... have a look at:

Ebean ORM (http://ebean-orm.github.io).

It's main claim would be a simpler more intuitive programming model than JPA or Hibernate. Specifically, it doesn't have a Hibernate Session or JPA EntityManager, no detached/attached objects (no merge, persist, flush), lazy loading just works.

... aka much simpler to use and understand.

You can also use your own SQL with Ebean (for queries, updates, stored procedures) and IMO it matches Ibatis in ease of use wrt using your own SQL.

If you are looking to use the ORM in Java SE then I'd suggest you check it out.

• LGPL Licence
• Use JPA annotations for mapping (@Entity, @OneToMany etc)
• Session-less API (no merge, persist, flush ... save() and delete() instead)
• "Partial Object" support
• Large Query support (per object graph persistence context)
• Background queries
• Good support for batch processing
• Automatic Query tuning (via "Autofetch")

Cheers, Rob.

---

We are currently working on a project which uses both Hibernate and ibatis. Why use hibernate ? It supports our domain model, relationships and inheritance. We have a pretty complex domain model and hiberante supports it very well. No need to worry about writing inserts, updates etc. Ibatis is used only for view. There are queries and we have view objects(similar to domain models but not domain models) which are mapped with queries. Ibatis returns the data in the view obejct you want without worrying about reading from result set , which you have to manage in Spring JDBC. Why do we that instead of using HQl or Spring JDBC ? The domain is so complex and when rendering view , we do calculations , group by and tons of native SQL functions. we do all that in query, use dynamic queries , manage conditions in ibatis and get a clean light weight object. Makes much more sense if you have to traverse down multiple layers to fetch data in hibernate So depending on your situation , you may want to use only one, both or may be none. But definitely, hibernate is not something you cannot live without.

---

Be aware that using JPA/Hibernate (and probably most other ORM solutions) in non-trivial multi-threaded applications can quickly become a real PITA because database sessions need to be confined to exactly one thread (Session objects are not thread-safe). Add lazy loading and the fact that persistent entities can belong to at most one active session...and you're in for a hell of a ride...

You might want to have a look at Session management using Hibernate in a *multi-threaded* Swing application (or just search for 'hibernate multi-threaded').

My rule of thumb (YMMV): If the application does not lend itself to some kind of request/response cycle (like a webservice for example) , you may probably be better off using something else.

Of course, another solution would be to design the application in a way that circumvents the mentioned framework limitations. Changing an application's design so I can get framework XYZ to work leaves a bad aftertaste though.

Anyway, just my $0.02

---

I think that we should take in consideration the main reason why we're using Java (or OO).

The system has to be flexible and allow constant modifications of the specification (this happens very often in real life). Otherwise we should have programmed in C, because it's a lot faster.

I think that the best stack for web applications would be Java EE: JPA - EJB - JSF (with extended persistence context conversation scoped).

JSF also is slower than pure JSP/Servlet, but it's faster to develop.

JPA is harder to learn, but it's faster to develop (you know: RAD) and changes don't have big (error prone copy-paste) impact. Add a new column in your most used entity, and you will have to update all statements in iBatis ...

JPA doesn't work very good on all cases, but it covers most of them, and it also let you plug Native Query instead of JPQL without changing any code. But if you find yourself writing too much Native Query your project's might fit better iBatis.

And as for performance, JPA is also performant if you understand how things translate to SQL, and if you put it to do what he is best at, if you put it to do something that's not comfortable for him, it will generate too much queries. There's no magic ! You have to be aware of the generated query, not blindly hope that you can take the easy way when some complicated case might appear.

Also if developers have all the capabilities of SQL they will write too complex queries to process business logic, instead of having it in a centralized place, you will have some business logic in SQL, some in EJB. JPA should be for persisting your model, not for Business Logic.

Criteria Query is also no match for building safe nomatterhowcomplex dynamic queries.

---

If you are indeed have a greenfield project, you may use hibernate, but be aware that the learning curve is quite steep.

If you have a existing database you are much better of with iBatis, because after one day you are productive and after two more days you can know all about it.

One thing you have to consider is, that the hibernate criteria api is excellent for creating custom queries, which depending on your application, may be a good argument for it.

---

If you don't have a good object model, I don't see the benefit of Hibernate. You certainly have the "relational" in ORM, since you have a relational database, but the "object" is key. No objects, no ORM. I think a 1:1 mapping between objects and tables, without richer object behavior, does not justify ORM. Stick with JDBC or iBatis if that's your situation.

---

I'd suggest going with JPA and depending (heavily!) on the duration/scope of your project you might as well look into JPA2, for it provides some of the missing features of JPA (a very nice Query API for example).

---

Go with hibernate. Your project will definitely grow larger later on and the investment (on learning hibernate) will pay off one way or another.

---

Have you tried to answer WHY even use an ORM tool before deciding which one to use? If you have people on your team who know SQL, see stick to JDBC.

참고URL : https://stackoverflow.com/questions/716532/hibernate-ibatis-java-ee-or-other-java-orm-tool