실제로 ORM이 아닌 새로운 Java 지속성 도구에 대해 어떻게 생각하십니까? [닫은]

자바에서의 지속성

지난 몇 년 동안 EJB 2.0, Hibernate, JPA 및 자체 개발 개념과 같은 개념을 사용하여 Java의 지속성 추상화 분야에서 경험을 쌓았습니다. 그들은 가파른 학습 곡선과 많은 복잡성을 가지고있는 것처럼 보였습니다. 또한 SQL의 큰 팬으로서 많은 추상화 모델이 SQL에 비해 너무 많은 추상화를 제공하여 "기준", "조건 자", "제한"과 같은 개념을 만들지 만 SQL은 아닌 개념을 만듭니다.

Java에서 퍼시스턴스 추상화의 일반적인 개념은 RDBMS가 어떻게 든 OO 세계와 일치하는 객체 관계형 모델을 기반으로하는 것 같습니다. ORM 토론은 항상 정서적 인 문제였습니다. 이러한 솔루션이 존재할 수 있다면 모든 사람에게 적합한 단일 솔루션이 존재하지 않는 것 같습니다.

주크

ORM 관련 문제를 피하는 방법에 대한 개인적 선호는 관계 세계에 충실하는 것입니다. 이제 데이터 모델 패러다임의 선택은 개인적인 취향이거나 구체적인 문제에 가장 적합한 데이터 모델의 문제이므로 토론 주제가되어서는 안됩니다. 내가 시작하고 싶은 토론은 jOOQ 라는 내 자신의 지속성 도구에 관한 것 입니다. 최신 지속성 도구의 장점을 대부분 제공하기 위해 jOOQ를 설계했습니다.

• SQL 기반 도메인 특정 언어
• 기본 데이터베이스 스키마를 Java로 맵핑하는 소스 코드 생성
• 많은 RDBMS 지원

최신 지속성 도구가 거의없는 몇 가지 기능 추가 (잘못된 경우 수정) :

• 복잡한 SQL 지원-공용체, 중첩 선택, 자체 조인, 앨리어싱, 사례 절, 산술 표현식
• 비표준 SQL-저장 프로 시저, UDT, ENUMS, 기본 함수, 분석 함수 지원

자세한 내용은 http://www.jooq.org/learn.php 문서 페이지를 참조 하십시오 . Linq는 SQL 전용으로 설계되지 않았지만 C # 용 Linq에서도 매우 유사한 접근 방식이 구현되어 있음을 알 수 있습니다.

질문

이제 저는 SQL의 열렬한 팬이라고 말하면서 다른 개발자가 jOOQ (또는 Linq)에 대한 열정을 나눌 지 궁금합니다. 지속성 추상화에 대한 이런 종류의 접근 방식이 실행 가능한가? 당신이 볼 수있는 장단점은 무엇입니까? jOOQ를 개선 할 수있는 방법과 의견에 무엇이 없는가? 개념적으로나 실제로 어디에서 잘못 되었습니까?

비판적이지만 건설적인 답변에 감사드립니다.

나는 토론이 감정적 인 것이라는 것을 이해합니다. 이미 비슷한 일을하는 많은 훌륭한 도구가 있습니다. 내가 관심있는 것은 당신이 읽은 경험 이나 기사를 바탕으로 중요하지만 건설적인 피드백 입니다.

나는 당신이 올바른 길을 가고 있다고 생각하고 솔루션을 계속해야합니다. 이전의 비판 중 일부는 지나치게 가혹하지만 일부 유효한 지적 사항이 있습니다.

나도 자신의 요구에 맞는 모든 기능을 갖춘 ORM 솔루션을 찾기 위해 오랫동안 열심히 노력했지만, 내가 본 모든 솔루션이 부족했습니다. 각각에는 장단점이 있지만 내가 원하는 모든 것을 실제로 한 것은 없습니다. 이러한 솔루션에 대한 귀하의 비판에 동의합니다. 즉, 일반적으로 솔루션이 복잡하고 학습 곡선이 가파르다는 점에 동의합니다.

최고의 경쟁자는 사실상 표준 인 최대 절전 모드 여야합니다. 모든 기능을 갖추고 강력하고 테스트를 거쳤습니다. 나는 그것을 존중하고 그것이 무엇인지 감사합니다. 이제는 프로그래밍 커뮤니티의 절반을 침해 할 위험이 있으며, 코드가 부풀어지고 복잡한 비 성능 코드라고 말해야합니다. 나는 장을 둘러보고, 디버깅하고 이해하려고 상당한 시간을 보냈으며, 내가 본 것에 감동하지 않았습니다. 그렇게 말하면서, 나는 여전히 좋은 ORM을 찾는 사람의 출발점으로 추천 할 것입니다. 간단한 CRUD는 뛰어나지 만 데이터 마이닝 또는 숫자 크 런칭과 같은 대량 대량 쿼리에는 사용하지 않습니다.

불행히도 내 응용 프로그램은 많은 수의 크 런칭 다양성 (CRUD도 있지만)이므로 롤링하기로 결정했습니다. 처음부터 그것이 다른 솔루션과 비교할 때 하위 수준이라는 것을 알고 있었지만 충분하고 나에게 필요한 성능을 제공합니다. 이제 여기 정말 큰 부분이 있습니다. 솔루션과 매우 비슷합니다!

이것이 내가 가장 옳은 일이라고 생각합니다. 당신은 근본적인 신념을 일종의 사명 선언으로 말했으며 그러한 신념은 정확합니다. 분명히이 문제에 대해서도 상당한 시간을 보냈으며 해결하기가 어렵습니다. 그러나 시간이 지남에 따라 프로그래밍 커뮤니티가 더 잘 이해하고 더 나은 솔루션을 만들 것이라고 생각합니다. 이전의 모든 노력 (특히 최대 절전 모드)에 대한 조언이지만 더 잘 할 수 있다고 생각합니다.

귀하의 솔루션은 문제를 개선하지만 문제의 일부만 해결합니다. 계층화 된 접근 방식으로 원하는 모든 것을 얻을 수 있다고 생각합니다. / IMO에서 생각해 낸 것은 기초 계층입니다. 제안한 바와 같이이 계층은 데이터베이스 스키마를 기반으로 자동 생성되는 것이 가장 좋습니다. 더 이상 데이터베이스에 직접 맵핑되지 않는 매우 단순한 관계형 오브젝트 모델이어야합니다. 데이터가 코드보다 훨씬 오래 지속되는 것이 맞습니다. 따라서이 수준에서는 데이터가 코드를 구동해야하며 그 반대도 마찬가지입니다. CRUD 및 성능 대량 쿼리를 지원합니다. 아마도이 계층에서 일종의 L1 캐시를 구현할 것입니다.

그러나 다른 ORM 솔루션의 장점은 기본 데이터베이스의 실제 구조에 크게 의존하지 않는 방식으로 개체를 정의 할 수 있다는 것입니다. 이 기능을 위해 다른 레이어를 만듭니다. 필요에 따라이 계층은 더 추상적이되고 희망적으로 단순 해졌으며 (기능 손실로 인해) 이전 계층을 기반으로합니다. L2 캐시를 활용할 수 있습니다.

더 많은 레이어를 사용할 수 있지만 핵심은 라이브러리에 여러 개의 진입 점을 제공함으로써 모든 요구를 충족시킬 수 있다는 것입니다. 선택한 객체에 직접 매핑되는 간단한 CRUD 솔루션을 원하는 사용자는 최상위 계층에서 빌드 할 수 있습니다. 더 강력하고 성능이 뛰어난 제품을 찾고 있지만 추가 된 복잡성을 유발하려는 경우 하위 계층에 연결할 수 있습니다. 특수 쿼리 언어를 만들지 않고 대신이 목적으로 쿼리 작성기 개체를 노출시킵니다. 또한 코드가 계층화되어 있기 때문에 특별한 통과없이 기능이 자연스럽게 존재합니다.

나는 당신이 공간을 이해하고 바퀴를 재발 명하지는 않지만 약간 다른 틈새 시장에 부딪쳤다 고 생각합니다. 솔직히 말해서, 이것은 어쨌든 개선을 사용할 수있는 바퀴입니다. 당신은 과거의 강국에 맞서 싸우는 오르막 전투에 직면했지만, 당신의 해결책이 좋으며, 그것이 그렇게 나아가고 있다고 생각한다면, 그것은 그 자체의 장점으로 인기를 얻을 것입니다.

"매력적인 총알이 있으며 순진한 개발자가 부족하지 않습니다."

불쾌하지 않습니다.이 공간에서 이미 수행 한 작업을 완전히 이해하지 못했기 때문에 일부 바퀴를 재발 명합니다. 경험에 따라 발명 한 바퀴가 깔끔하고 재미있을 것 같지는 않습니다. 이미 사용 가능한 멋지게 정제 된 휠로 유용하거나 유용합니다.

이러한 종류의 API를 적합하게 만드는 한 가지 시나리오는 대부분의 ORM에서 허용하지 않는 데이터베이스 독립적 SQL 빌더가 필요한 경우입니다. 내가 필요한 한 가지 큰 상황은 보고서를 생성하는 것입니다. 객체 지향 방식으로 SQL을 작성하고 테스트를 위해 다양한 데이터베이스 에서이 SQL을 실행해야했습니다. 최대 절전 모드 및 기타 ORM은 구성에 매우 의존하므로 xml에 연관이 존재하지 않는 테이블을 결합 할 수 없도록 SQL 구성을 제한합니다. 개발중인 보고서 모듈에서 모든 연관이 가능하므로 다른 것을 찾아 보았습니다. 그런 다음 나는 JOOQ를 만났다. 그냥 내 문제를 해결합니다. 읽기 전용 액세스가 필요했으며 최대 절전 모드와 같은 고통스러운 디버깅 문제가 발생하지 않았습니다.

실제로 일반적인 POJO 방식이 아닌 다른 데이터 모델링 방식을 개발하고 SQL을 구축하기위한 계층 중 하나로서 JOOQ를 사용할 계획입니다. 따라서 JOOQ 외에도 HashMaps를 사용하여보다 유연한 데이터 / 엔터티 모델링 방법을 만들 계획입니다. 위 디자인에서 언급 한 것처럼 다양한 레이어를 사용하여 프레임 워크를 완성하기는했지만 내 디자인에서는 프런트 엔드 및 백엔드 디자인을 하나의 진입 점에 쉽게 통합 할 수있었습니다. JOOQ는 저의 프로젝트 에서처럼 아주 훌륭한 역할을 할 것입니다. 그것은 기초 또는 기둥 중 하나입니다.

따라서 좋은 일 루카를 유지하십시오!

도구를 올바르게 이해하면 ORM과 거의 비슷한 SQL 기능 (ORM)에 대한 매핑을 구현하는 객체를 매핑하는 대신 개념적 SQL 프레임 워크에 객체를 직접 매핑하여 더 많은 괴짜 제어를 위해 더 많은 SQL 기능을 사용할 수 있습니다. ORM은 보통 당신에게 줄 것입니까?

어떤 문제를 해결하려고하는지 잘 모르겠습니다. 도구에 SQL에 대한 심층적 인 지식이 필요하기 때문에 사람들이 SQL을 사용하지 않습니까? 제거하려는 접착제 코드입니까? 간단한 문자열 대신 API 모델링을 통해 SQL 쿼리의 유효성을 검사합니까?

JOOQ 예제는 LISP 버전의 SQL과 같다는 것을 인정해야합니다. 그것은 나쁜 일이 아닙니다 :) 그리고 나는 고급 것들 중 일부가 흥미 롭다는 것을 알지만, 당신이 나열하는 장점은 점점 더 발전함에 따라 천천히 사라집니다 (더 많은 구성, 덜 추상적이며 특정 SQL의 내부 성소에 더 깊이 뿌리 박음) 엔진 등)

내가 대부분의 ORM에서 놓치고 싶다는 한 가지 제안은 객체와의 상호 작용을 백엔드 (SQL, NoSQL, Topic Maps, RDF 등)로 변환하는 비 관계형 방식으로 객체를 처리 할 수있는 프레임 워크입니다. .) 특정 SQL 상호 작용, 방언 및 관계형 사고보다는 사용 된 모델의 캐싱이 필요합니다 .

물론 IMHO. :)