구현에 무관심한 가치가 있습니까?

현재 Tomcat, Spring 4, Spring Security, MySQL 및 JPA w / Hibernate를 사용하여 작업중 인 프로젝트가 있습니다.

나는 ORM 제공자의 기본 구현을 매끄럽게 또는 최소한 덜 고통스럽게 만드는 것으로 생각한다는 관점에서 JPA를 선택했습니다. 이것이 자바 구현 커뮤니티의 기본 관점 인 구현에 대한 스펙 (JAX-RS)을 정신적으로 사용하고 있다고 말하고 싶습니다.

이것이 정말로할만한 일인지 궁금합니다. 필자가 Hibernate를 직접 사용한다면 기본 JPA 사양에 포함되지 않은 기능을 사용할 수 있기 때문에 약간의 힘을 얻게 될 것입니다.

내 우려의 일부는 YAGNI의 아이디어에서 비롯됩니다. 나는 본질적으로 특정 스타일과 방식으로 프로그래밍하고 있으며 (Hibernate 대신 JPA를 사용하여) 나중에 어느 시점에서 ORM 구현을 바꿀 수 있습니다. 나는 그것이 제품의 수명 동안 일어날 것이라는 것을 심각하게 의심하므로, 본질적으로 결코 이익을 얻지 못할 무언가에 노력을 기울이고 있습니다.

당신의 생각은 무엇입니까? JPA와 같은 경우 "인터페이스 프로그래밍"이 가치가 있습니까? 실제로 제품에서 전체 ORM 구현을 교체 한 적이 있습니까? 어쨌든 JPA 유출과 같은 추상화를 완전히 피할 수 있습니까? 나는 개인적으로 이미 데이터베이스 테이블을 정리하기 위해 단일 네이티브 SQL 호출을 가지고 있으며 JPA 사양 (메소드의 get / set 접두사 및 MEMBER OF의 차이점)에 내장 된 것과 같은 것들이 있습니다 기본 구현에만 바인딩하는 / IN을 사용하면 피할 수 있습니다.

앞으로 어느 시점에서 ORM 구현을 바꿀 수 있습니다. 나는 그것이 제품의 수명 동안 일어날 것이라는 것을 심각하게 의심한다. 그래서 나는 본질적으로 아마도

내 경험상 일반적인 엔터프라이즈 프로젝트는 결코 스왑 아웃되지 않습니다.

1. 데이터 베이스
2. ORM
3. 언어

나는 숫자를 모르지만 내가 본 2 계층 앱의 백분율은 구현 한 다음 그 중 하나를 변경하면 아마도 10 % 미만 일 것입니다. 발생하는 경우는 드물며 사람들이 여전히 검색 모드에있는 프로젝트의 처음 2-3 개월 내에 발생합니다. 내가 아는 대부분의 시스템은 8-10 년 후에도 여전히 원래 플랫폼에서 실행되고 있습니다.

ORM을 바꾸는 것보다 더 자주 내가 본 것을 더 알고 싶습니까? 성능 문제로 인해 ORM을 완전히 제거하여 SQL로 드롭 다운합니다. 따라서 어떤 경우이든, 당신은 물건을 다시 쓸 것입니다.

구현에 구애받지 않는 한 그 신화. 정말 바보 같아요. 내 접근 방식은 데이터 계층을 수용하는 것입니다. 당신의 언어와 디자인의 일급 부분으로 만드십시오. 더 행복하고 성공적인 프로젝트를 만듭니다.

그만한 가치가 있습니까?
그것은 전적으로 응용 프로그램에 달려 있습니다.
단일 회사의 내부 응용 프로그램을 작성하는 경우 잊어 버리십시오. 이 데이터베이스는 수년, 수십 년 동안 애플리케이션보다 오래 지속될 것입니다.
물론 데이터베이스가 가까운 장래에 다른 것으로 대체 될 계획이라는 것을 처음부터 이해하도록 제공되지 않았다면.
다른 데이터베이스 엔진을 보유한 고객에게 판매용으로 작성하고 있으며 여러 데이터베이스 엔진을 지원해야하는 요구 사항이있는 경우에는 이치에 맞습니다.

대부분의 사람들은 Java 응용 프로그램을 작성하는데 크게 관련이 없습니다.

내 경험으로는 : 아니요, JPA / Hibernate의 경우에는 가치가 없습니다 .

JPA와 같은 경우 "인터페이스 프로그래밍"이 가치가 있습니까?

JPA와는 특별히 관련이 없습니다. Hibernate의 "인터페이스 프로그래밍"을 할 수 있습니다. 이것은 표준에서 프레임 워크를 숨기는 것이 아니라 SOLID 입니다.

실제로 제품에서 전체 ORM 구현을 교체 한 적이 있습니까?

예, 아니오 회사 제품 중 하나가 Hibernate에서 jOOQ (JPA와는 아무런 관련이 없음)로 부분적으로 마이그레이션되었습니다. @codenheim이 언급 한 것은 "일반적인 엔터프라이즈 프로젝트"가 아니기 때문에 스와핑이 가능했습니다.

다른 JPA 호환 ORM과 Hibernate를 교환 할 필요가 없습니다.

어쨌든 JPA 유출과 같은 추상화를 완전히 피할 수 있습니까?

아니요. JPA와 최대 절전 모드가 모두 복잡하기 때문에 불가능합니다. 그리고 어쨌든 Hibernate의 성능 문제와 디자인 결함을 처리해야합니다.

여기서 반대하는 소리가 들릴 위험이 있습니다. 그렇습니다. 그리고 그렇지 않습니다.

ORM 또는 데이터베이스 공급자를 전환하는 데 문제는 그리 많지 않습니다. 우려를 분리하고 민첩성을 유지하는 것이 더 중요합니다.

라이브러리의 구현 세부 사항에 의존하기 시작하면 더 깊고 더 깊은 관심사를 만들기 시작합니다.

ORM 구현이 Hibernate라는 모자를 알고 있다면,이 지식은 애플리케이션의 전체 아키텍처를 파악하기 시작합니다. 그리고 Hibernate가 이전에했던 것만 큼 철저하게 Hibernate 또는 JPA를 대체하는 새로운 기술이 등장 할 때마다 종속성이 예상보다 훨씬 깊어졌습니다.

데이터베이스와 트랜잭션을 다루는 모든 복잡한 과정과 그 밖의 모든 부분을 나머지 응용 프로그램에서 쉽게 무시할 수있는 방법으로 모델을 유지하는 데 대한 모든 관심을 없애는 것이 훨씬 좋습니다. 그 어두운 곳에서, 원하는 경우 특정 구현 세부 사항을 매듭으로 묶을 수 있습니다. 더 이상 중요하지 않습니다.

구현 불가지론의 문제점은 개발자로서 당신의 시간에 어느 쪽이든 시간을 낭비한다는 것입니다.

인터페이스에 쓰는 데 많은 시간을 낭비한 몇 가지 프로젝트를 작성했습니다. 그런 다음 새로운 방식으로 사용되지 않았으며 변환되지 않고 수년 동안 '있는 그대로'사용되지 않았습니다.

또한 아무도 변환 할 필요가없는 소프트웨어를 변환하는 데 많은 시간을 낭비했습니다.

내가해야 할 유일한 실제 관찰은 전자가 훨씬 덜 고통 스럽다는 것입니다.