자바-JDBC 대안
이것은 단지 이론적 인 질문입니다.
데이터베이스 (선택, 삽입, 업데이트, 삭제 등)를 사용하기 위해 Java 애플리케이션과 함께 JDBC를 사용합니다. DB 테이블 (속성 = db 열)의 데이터를 포함 할 "수동"Java 클래스를 만듭니다. 그런 다음 쿼리 (ResultSet)를 만들고 해당 클래스를 데이터로 채 웁니다. 이것이 올바른 방법인지 확실하지 않습니다.
하지만 JDO와 다른 지속성 솔루션에 대해 많이 읽었습니다.
누군가 자신의 경험을 바탕으로 가장 많이 사용되는 JDBC 대안을 추천 해 주시겠습니까?
또한 JDBC에 비해 JDO의 장점을 알고 싶습니다 (간단한 말로).
저는 이런 것들을 많이 구글링 할 수 있었지만 "직접"의 의견은 항상 최고입니다.
감사
Java의 데이터베이스 지속성 이야기는 이미 길고 우여곡절로 가득 차 있습니다.
JDBC 는 모든 사람 이 데이터베이스와 통신하기 위해 마지막에 사용 하는 저수준 API입니다 . 하지만 더 높은 수준의 API를 사용하지 않고 모든 지저분한 작업을 직접 수행해야합니다 (SQL 쿼리 작성, 결과를 개체에 매핑 등).
EJB 1.0 CMP Entity Beans 는 상위 레벨 API에 대한 첫 번째 시도였으며 사용자가 아닌 대형 Java EE 공급자 (BEA, IBM)에서 성공적으로 채택했습니다. Entity Bean은 너무 복잡하고 오버 헤드가 너무 많았습니다 (이해, 성능 저하). 불합격!
EJB 2.0 CMP 는 로컬 인터페이스를 도입하여 Entity Bean의 복잡성을 일부 줄이려고 시도했지만 대부분의 복잡성은 그대로 유지되었습니다. EJB 2.0은 이식성이 부족했습니다 (객체 관계형 매핑이 사양의 일부가 아니기 때문에 배포 설명자가 독점적이기 때문입니다). 불합격!
그리고 온 JDO 이다 오브젝트 지속성에 대한 데이터 저장소 불가지론 표준 (RDBMS, OODBMS, XML, 엑셀, LDAP와 함께 사용할 수 있습니다). 그러나 여러 오픈 소스 구현이 있고 JDO가 소규모 독립 공급 업체 (대부분 OODBMS 공급 업체가 나중에 JDO 사용자가 RDBMS 데이터 저장소에서 OODBMS로 전환하기를 바라지 만, 이는 분명히 발생하지 않았 음)에 의해 채택되었지만 실패했습니다. 큰 Java EE 플레이어 및 사용자가 채택했습니다 (개발시 고통스럽고 일부 고객은 이상한 쿼리 API로 인해 실제로 너무 추상적이기 때문에). 따라서 표준 자체는 죽지 않았지만 실패로 간주합니다. 불합격!
그리고 실제로 두 가지 표준이 있음에도 불구하고 Toplink , 오래된 플레이어 또는 Hibernate 와 같은 독점 API는 EJB CMP 및 JDO보다 객체 대 관계형 데이터베이스 지속성 (표준 간의 경쟁, JDO의 명확하지 않은 포지셔닝, 이전 실패 CMP와 나쁜 마케팅이 책임의 일부를 가지고 있다고 생각합니다) 그리고 Hibernate는 실제로이 분야에서 사실상의 표준이되었습니다 (훌륭한 오픈 소스 프레임 워크입니다). 성공!
그런 다음 Sun은 작업을 단순화해야한다는 것을 깨달았고 (일반적으로 전체 Java EE) Java EE 5 에서 EJB 3.0의 일부이며 관계형 데이터베이스 지속성을위한 새로운 표준 인 JPA 인 Java Persistence API를 사용하여이를 수행했습니다. . JPA는 EJB 2 CMP, JDO, Hibernate 및 TopLink API / 제품을 통합하고 EJB CMP 및 JDO가 실패한 경우 (사용 및 채택 용이성) 성공한 것으로 보입니다. 성공!
요약하면, 데이터베이스 지속성에 대한 Java의 표준 은 JPA 이며 ORM이 필요하지 않은 경우가 아니면 다른 독점 API (Hibernate의 JPA 구현은 괜찮지 만 JPA API를 사용)보다 선호되어야합니다. JDBC보다 더 높은 수준의 API를 제공하며 많은 수작업을 절약 할 수 있습니다 (간단하지만 아이디어입니다).
SQL을 직접 작성하고 ORM을 원하지 않는 경우에도 모든 지루한 연결 처리 (try-catch-finally)를 숨기는 일부 프레임 워크의 이점을 누릴 수 있습니다. 결국 당신은 연결을 끊는 것을 잊을 것이다 ...
매우 사용하기 쉬운 프레임 워크 중 하나는 Spring JdbcTemplate 입니다.
Hibernate 를 추천 할 수 있습니다 . 그것은 널리 사용되며 (그리고 정당한 이유로), Java Persistence API 사양이 Hibernate의 메인 디자이너에 의해 주도 되었다는 사실 은 그것이 가까운 미래에있을 것이라는 것을 보장합니다 :-) 이식성과 벤더 중립성이 당신에게 중요하다면 , JPA를 통해 사용할 수 있으므로 나중에 다른 JPA 구현으로 쉽게 전환 할 수 있습니다.
JDO에 대한 개인적인 경험이 없기 때문에 두 가지를 실제로 비교할 수는 없습니다. 그러나 Hibernate (또는 일반적으로 ORM)의 이점은 JDO 페이지 에 나열된 것과 거의 동일한 것 같습니다 . 나에게 가장 중요한 점은 다음과 같습니다.
- DB 중립성 : Hibernate는 백그라운드에서 여러 SQL 언어를 지원합니다. DB 간 전환은 구성에서 한 줄을 변경하는 것만 큼 쉽습니다.
- 성능 : 기본적으로 지연 가져 오기 및 JDBC로 수동으로 처리해야하는 훨씬 더 많은 최적화가 내부에서 진행됩니다.
- 하위 수준의 DB 문제 대신 도메인 모델 및 OO 디자인에 집중할 수 있습니다 (원하는 경우 DML 및 DDL을 미세 조정할 수 있음).
일반적으로 ORM 도구의 한 가지 잠재적 인 단점은 일괄 처리에 적합하지 않다는 것입니다. 테이블에서 1 백만 개의 행을 업데이트해야하는 경우 ORM은 기본적으로 JDBC 일괄 업데이트 또는 저장 프로시 저만큼 수행하지 않습니다. Hibernate는 저장 프로 시저를 통합 할 수 있으며 어느 정도 일괄 처리를 지원합니다 (아직 익숙하지 않으므로 JDBC와 비교하여이 점에서 작업에 달려 있는지 여부를 실제로 말할 수는 없습니다. 지금까지 알고, 아마도 예). 따라서 앱에 일괄 처리가 필요하지만 대부분 개별 엔터티를 처리하는 경우 Hibernate는 여전히 작동 할 수 있습니다. 주로 일괄 처리를 수행하는 경우 JDBC가 더 나은 선택 일 수 있습니다.
Hibernate는 스키마를 매핑 할 개체 모델이 있어야합니다. 여전히 관계형 스키마와 SQL의 관점에서만 생각하고 있다면 Hibernate가 적합하지 않을 것입니다.
Hibernate가 생성 할 SQL을 기꺼이 받아 들여야합니다. 직접 코딩 한 SQL로 더 잘할 수 있다고 생각한다면 Hibernate가 적합하지 않을 것입니다.
또 다른 대안은 iBatis입니다. JDBC가 원시 SQL이고 Hibernate가 ORM이면 iBatis는 둘 사이의 것으로 생각할 수 있습니다. 실행되는 SQL을 더 잘 제어 할 수 있습니다.
JDO는 JDBC 기술을 기반으로합니다. 마찬가지로 Hibernate는 여전히 JDBC를 필요로합니다. JDBC는 데이터베이스 연결에 대한 Java의 기본 사양입니다.
이것은 JDBC가 더 큰 제어를 제공하지만 더 많은 배관 코드가 필요함을 의미합니다.
JDO는 많은 복잡성이 숨겨져 있기 때문에 더 높은 추상화와 더 적은 배관 코드를 제공합니다.
이 질문을한다면 JDBC에 익숙하지 않은 것 같습니다. JDO, Hibernate 또는 기타 더 높은 추상화 도구를 효과적으로 사용하려면 JDBC에 대한 기본적인 이해가 필요하다고 생각합니다. 그렇지 않으면 ORM 도구가 이해하지 못하는 동작을 보이는 시나리오가 발생할 수 있습니다.
웹 사이트에있는 Sun의 Java 튜토리얼은 JDBC를 안내하는 적절한 입문 자료를 제공합니다. http://java.sun.com/docs/books/tutorial/jdbc/ .
MyBatis를 살펴보십시오. 종종 간과되지만 DBMS의 독점 기능을 사용하는 복잡한 읽기 전용 쿼리에 적합합니다.
JPA/Hibernate is a popular choice for ORM. It can provide you with just about every ORM feature that you need. The learning curve can be steep for those with basic ORM needs.
There are lots of alternatives to JPA that provide ORM with less complexity for developers with basic ORM requirements. Query sourceforge for example: http://sourceforge.net/directory/language:java/?q=ORM
I am partial to my solution, Sormula: sourceforge or bitbucket. Sormula was designed to minimize complexity while providing basic ORM.
Hibernate, surely. It's popular, there is even a .NET version.
Also, hibernate can be easily integrated with Spring framework.
And, it will mostly fit any developer needs.
A new and exciting alternative is GORM, which is the ORM implementation from Grails. Can now be used stand alone. Under the hood it uses Hibernate, but gives you a nice layer on top with cool dynamic finders etc.
All these different abstraction layers eventually use JDBC. The whole idea is to automate some of the tedious and error prone work much in the same way that compilers automate a lot of the tedious work in writing programs (resizing a data structure - no problem, just recompile).
Note, however, that in order for these to work there are assumptions that you will need to adhere to. These are usually reasonable and quite easy to work with, especially if you start with the Java side as opposed to have to work with existing database tables.
JDO is the convergence of the various projects in a single Sun standard and the one I would suggest you learn. For implementation, choose the one your favorite IDE suggests in its various wizards.
There is also torque (http://db.apache.org/torque/) which I personally prefer because it's simpler, and does exactly what I need.
With torque I can define a database with mysql(Well I use Postgresql, but Mysql is supported too) and Torque can then query the database and then generate java classes for each table in the database. With Torque you can then query the database and get back Java objects of the correct type.
It supports where clauses (Either with a Criteria object or you can write the sql yourself) and joins.
It also support foreign keys, so if you got a User table and a House table, where a user can own 0 or more houses, there will be a getHouses() method on the user object which will give you the list of House objects the user own.
To get a first look at the kind of code you can write, take a look at http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.html which contains examples which show how to load/save/query data with torque. (All the classes used in this example are auto-generated based on the database definition).
Here is how it goes with java persistence. You have just learnt java, now you want to persist some records, you get to learn JDBC. You are happy that you can now save your data to a database. Then you decide to write a bit bigger application. You realize that it has become tedious to try, catch , open connection, close connection , transfer data from resultset to your bean .... So you think there must be an easier way. In java there is always an alternative. So you do some googling and in a short while you discover ORM, and most likely, hibernate. You are so exited that you now dont have to think about connections. Your tables are being created automatically. You are able to move very fast. Then you decide to undertake a really big project, initially you move very fast and you have all the crud operations in place. The requirements keep comming, then one day you are cornered. You try to save but its not cascading to the objects children. Somethings done work as explained in the books that you have read. You dont know what to do because you didnt write the hibernate libraries. You wish you had written the SQL yourself. Its now time to rethink again... As you mature , you realize that the best way to interact with the Database is through SQL. You also realize that some tools get you started very fast but they cant keep you going for long. This is my story. I am now a very happy ibatis/User.
Ebean ORM is another alternative http://ebean-orm.github.io/
Ebean uses JPA Annotations for Mapping but it is architected to be sessionless. This means that you don't have the attached/detached concepts and you don't persist/merge/flush - you just simply save() your beans.
- I'd expect Ebean to be much simplier to use than Hibernate, JPA or JDO
So if you are looking for a powerful alternative approach to JDO or JPA you could have a look at Ebean.
I recommend to use the Hibernate, its really fantastic way of connecting to the database, earlier there were few issues, but later it is more stable. It uses the ORM based mapping, it reduces your time on writing the queries to an extent and it allows to change the databases at a minimum effort. If you require any video based tutorials please let me know I can uplaod in my server and send you the link.
Here is how it goes with java persistence. You have just learnt java, now you want to persist some records, you get to learn JDBC. You are happy that you can now save your data to a database. Then you decide to write a bit bigger application. You realize that it has become tedious to try, catch , open connection, close connection , transfer data from resultset to your bean .... So you think there must be an easier way. In java there is always an alternative. So you do some googling and in a short while you discover ORM, and most likely, hibernate. You are so exited that you now dont have to think about connections. Your tables are being created automatically. You are able to move very fast. Then you decide to undertake a really big project, initially you move very fast and you have all the crud operations in place.
Use hibernate as a stand alone JAR file then distribute it to your different web apps. This far is the best solution out there. You have to design your Classes, Interfaces, Enums to do an abstract DAO pattern. As long as you have correct entities and mappings. You will only need to work with Objects(Entities) and not HSQL.
참고URL : https://stackoverflow.com/questions/2397016/java-jdbc-alternatives
'IT TIP' 카테고리의 다른 글
| Lodash를 사용하여 값별로 개체 배열 정렬 (0) | 2020.11.22 |
|---|---|
| 전역 변수 앞에 정적 키워드를 언제 사용합니까? (0) | 2020.11.22 |
| 파이썬 distutils를 설치하는 방법 (0) | 2020.11.22 |
| 파이썬에서 '어떤'동등한 기능 (0) | 2020.11.22 |
| 데이터 세트-차량 제조업체 / 모델 / 년 (무료) (0) | 2020.11.22 |