언제 ORM 접근 방식을 사용하여 완전히 집중할 수 있거나 해야 합니까?

Question

내 생각에는 ORM 도구를 도입하면 아키텍처가 더 깔끔해지기 마련이지만 효율성을 위해 가끔 ORM 도구를 우회하고 JDBC 결과 세트를 반복하는 경우가 있습니다.이는 더 깔끔한 아키텍처 대신 조정되지 않은 아티팩트 엉킴으로 이어집니다.

잘못된 컨텍스트에서 도구를 적용하고 있기 때문인가요, 아니면 그보다 더 깊은가요?

언제 ORM 접근 방식을 사용하여 완전히 집중할 수 있거나 해야 합니까?

어떤 통찰력이라도 대단히 감사하겠습니다.

---

약간의 배경지식:

내 환경에는 약 50대의 클라이언트 컴퓨터와 상당히 강력한 SQL Server 1대가 있습니다.

50명의 클라이언트 모두가 항상 데이터에 액세스하는 데스크톱 응용 프로그램이 있습니다.

프로젝트의 데이터 모델은 명확성, 효율성 등 다양한 이유로 여러 차례 재구성되었습니다.

내 데이터 모델의 역사

1. JDBC가 직접 호출
2. Pojos 간의 관계가 없는 DAO + POJO(기본적으로 JDBC 래핑)
3. Lazy Loading을 구현하는 POJO 간의 관계를 추가했지만 DAO 간 호출만 숨겼습니다.
4. Hibernate가 데이터 액세스를 얼마나 "단순하게" 만들고(POJO 간 관계를 사소하게 만드는지) 많은 관련 엔터티와 작업할 때 데이터베이스 왕복 횟수를 줄일 수 있다는 것을 확인한 후 Hibernate의 편에 섰습니다.
5. 세션을 장기간 열어두는 데스크톱 애플리케이션이었기 때문에 악몽이었으며 결국 많은 문제를 일으켰습니다.
6. Hibernate를 사용하는 동시에 DAO 커튼 뒤에서 직접 JDBC 호출을 할 수 있게 해주는 부분적인 DAO/Hibernate 접근 방식으로 물러났습니다.

Answer 1

Hibernate는 애플리케이션이 작동할 때 더 의미가 있습니다. 객체 그래프, 이는 RDBMS에 유지됩니다.대신, 애플리케이션 로직이 2-D 데이터 매트릭스에서 작동하는 경우 직접 JDBC를 통해 해당 데이터를 가져오는 것이 더 좋습니다.Hibernate는 JDBC 위에 작성되었지만 JDBC에서 구현하기가 쉽지 않은 기능을 가지고 있습니다.예를 들어:

1. 사용자가 UI에서 행을 보고 일부 값을 변경한 후 실제로 변경된 열에 대해서만 업데이트 쿼리를 실행하려고 한다고 가정해 보겠습니다.
2. 교착 상태에 빠지지 않으려면 트랜잭션에서 SQL의 전역 순서를 유지해야 합니다.올바른 JDBC를 얻는 것은 쉽지 않을 수 있습니다.
3. 낙관적 잠금을 쉽게 설정할 수 있습니다.JDBC를 사용하는 경우 모든 업데이트 쿼리에 이를 포함해야 한다는 점을 기억해야 합니다.
4. 일괄 업데이트, 컬렉션의 지연 구체화 등도 JDBC에서 구현하는 것이 쉽지 않을 수 있습니다.

(내가 말하다 "~할 것 같다 사소하지 않게 행동하세요. 왜냐하면 물론 그렇게 할 수 있기 때문입니다. 그러면 당신은 슈퍼 해커가 될 수도 있습니다. :)

Hibernate를 사용하면 필요할 경우 자신만의 SQL 쿼리를 실행할 수도 있습니다.

이것이 결정하는 데 도움이 되기를 바랍니다.

추신:원격 데스크톱 클라이언트에서 세션을 열어두고 문제에 부딪히는 것은 실제로 Hibernate의 문제가 아닙니다. DB에 대한 연결을 오랫동안 열어두면 동일한 문제에 부딪힐 것입니다.