ORM을 통해 리치 도메인 모델을 만들 수 있습니까?

약 8 년 동안 대부분의 프로젝트에서 Hibernate를 사용한 후, 나는 사용을 권장하지 않고 저장 프로 시저를 통해서만 응용 프로그램이 DB와 ​​상호 작용하기를 원하는 회사에 착륙했습니다.

몇 주 동안이 작업을 수행 한 후, 구축하려는 애플리케이션의 리치 도메인 모델을 만들 수 없었으며 애플리케이션은 (끔찍한) 트랜잭션 스크립트처럼 보입니다.

내가 찾은 문제 중 일부는 다음과 같습니다.

• 저장 프로 시저가 단지 최소량의 데이터를로드하기 때문에 객체 그래프를 탐색 할 수 없습니다. 이는 때때로 다른 필드를 가진 유사한 객체가 있음을 의미합니다. 예를 들면 다음과 같습니다. 고객으로부터 모든 데이터를 검색하는 저장 프로 시저와 고객으로부터 계정 정보와 몇 가지 필드를 검색하는 저장 프로 시저가 있습니다.
• 많은 논리가 도우미 클래스로 끝나므로 코드가 더 체계화됩니다 (오래된 C 구조체로 사용되는 엔터티 사용).
• 저장 프로 시저에서 결과 집합을 추출하여 엔터티에 넣는 프레임 워크가 없으므로 더 지루한 스캐 폴딩 코드입니다.

내 질문은 :

• 비슷한 상황에 처한 사람이 있고 저장 프로 시저 접근 방식에 동의하지 않았습니까? 뭐 했어?
• 저장 프로 시저를 사용하면 실제로 이점이 있습니까? "아무도 드롭 테이블을 발행 할 수 없습니다"라는 어리석은 점을 제외하면
• 저장 프로 시저를 사용하여 리치 도메인을 만드는 방법이 있습니까? 개체 그래프를 탐색 할 수 있도록 AOP를 사용하여 DAO / 리포지토리를 엔터티에 주입 할 가능성이 있음을 알고 있습니다. 부두와 매우 가까워서이 옵션이 마음에 들지 않습니다.

결론

먼저 답변을 주셔서 감사합니다. 내가 도착한 결론은 ORM이 (리치 도메인 모델)을 만들 수는 없지만 (일부 사람들이 언급 한 것처럼) 반복되는 작업량을 단순화한다는 것입니다. 다음은 결론에 대한 자세한 설명이지만 하드 데이터를 기반으로하지는 않습니다.

대부분의 응용 프로그램은 다른 시스템에 정보를 요청하고 보냅니다. 이를 위해 모델 용어 (예 : 비즈니스 이벤트)로 추상화를 작성하고 도메인 모델은 이벤트를 보내거나받습니다. 이벤트에는 일반적으로 모델의 정보 중 일부만 필요하지만 전체 모델은 아닙니다. 예를 들어 온라인 상점에서 지불 게이트웨이는 일부 사용자 정보 및 총계를 요청하여 사용자에게 청구하지만 구매 내역, 사용 가능한 제품 및 모든 고객 기반을 요구하지는 않습니다. 따라서 이벤트에는 작고 구체적인 데이터 세트가 있습니다.

응용 프로그램의 데이터베이스를 외부 시스템으로 사용하는 경우 도메인 모델 엔터티를 데이터베이스에 매핑 할 수있는 추상화를 만들어야합니다 ( NimChimpsky가 언급 한 것처럼 데이터 매퍼 사용). 명백한 차이점은 이제 각 모델 엔터티에 대한 데이터베이스 (레거시 스키마 또는 저장 프로 시저)에 대한 매핑을 수작업으로 만들어야한다는 것입니다. 두 개가 동기화되지 않기 때문에 하나의 도메인 엔터티가 부분적으로 매핑 될 수 있습니다. 데이터베이스 엔터티 (예 : 사용자 이름과 암호 만 포함하는 UserCredentials 클래스가 다른 열이있는 Users 테이블에 매핑 됨)에 연결되거나 하나의 도메인 모델 엔터티가 둘 이상의 데이터베이스 엔터티에 매핑 될 수 있습니다 (예 : 테이블에 하나의 매핑이 있지만 모든 데이터는 하나의 클래스에 있어야합니다.

엔터티가 적은 응용 프로그램에서는 엔터티를 가로 질러야 할 필요가없는 경우 추가 작업의 양이 적을 수 있지만 엔터티를 가로 질러야하는 조건부 필요가있을 때 증가합니다. 적재 '). 응용 프로그램이 더 많은 엔터티를 갖도록 증가함에 따라이 작업은 증가합니다 (비선형으로 증가하는 느낌이 있습니다). 여기서 내 가정은 ORM을 재발 명하려고 시도하지 않는다는 것입니다.

DB를 외부 시스템으로 취급 할 때 얻을 수있는 이점 중 하나는 응용 프로그램마다 서로 다른 매핑이있는 두 가지 버전의 응용 프로그램을 실행하려는 상황을 코딩 할 수 있다는 것입니다. 이것은 생산으로의 지속적인 납품 시나리오에서 더욱 흥미로워집니다. 그러나 이것은 ORM을 통해 가능할 수도 있습니다.

개발자가 데이터베이스에 액세스 할 수없는 경우에도 악의적 인 코드를 삽입하여 시스템에 저장된 모든 정보를 얻을 수는 없지만 대부분의 경우 보안 측면을 무시합니다. 친애하는 주님, 고객의 신용 카드 정보를 기록하는 행을 제거하는 것을 잊어 버렸습니다 .)

작은 업데이트 (2012 년 6 월 6 일)

스토어드 프로 시저 (적어도 Oracle에서)는 테이블 구조를 변경하면 프로 시저 및 트리거가 무효화되므로 가동 중지 시간없이 지속적인 전달을 수행하지 않습니다. 따라서 DB가 업데이트되는 동안 응용 프로그램도 다운됩니다. 오라클은이를 위해 Edition-Based Redefinition 이라는 솔루션 을 제공 하지만,이 기능에 대해 물어 본 소수의 DBA는 제대로 구현되지 않았으며 프로덕션 DB에 넣지 않을 것이라고 언급했습니다.

응용 프로그램은 여전히 ​​도메인 기반 설계 원칙에서 모델링되어야합니다. SP를 호출하는 ORM, 직선 JDBC를 사용하든 상관없이 상관 없습니다 . SP에서 모델을 추상화하는 얇은 레이어 가이 경우 트릭을 수행하기를 바랍니다. 마찬가지로 다른 포스터가 언급 한 , 당신은의 SP 및 서비스로 결과를 확인하고 도메인 모델에 결과를 매핑해야합니다.

저장 프로 시저를 사용하면 실제로 이점이 있습니까?

금융 세계 (및 Sarbanes-Oxley 준수가 필요한 장소 )에서는 시스템이 감사해야 할 작업을 수행하도록 시스템을 감사 할 수 있어야합니다. 이 경우 모든 데이터 액세스가 저장 프로 시저를 통해 수행 될 때 규정 준수가 훨씬 쉬워집니다. 또한 임시 SQL을 모두 제거하면 숨기는 것이 훨씬 어렵습니다. 이것이 "좋은 것"인 이유의 예를 위해, 나는 Ken Thompson의 고전적인 논문 인 Trusting Trust에 대한 Reflections를 참조합니다 .

저장 프로시 저는 클라이언트 쪽 SQL 코드보다 훨씬 효율적입니다. 이들은 DB에서 SQL을 사전 컴파일하여 일부 최적화를 수행 할 수도 있습니다.

구조적으로 SP는 작업에 필요한 최소 데이터를 반환합니다. 이는 데이터 전송이 적다는 것을 의미하기 때문에 좋습니다. 이러한 아키텍처가 있다면 DB를 서비스로 생각해야합니다 (웹 서비스라고 생각하면 각 SP는 호출하는 방법입니다). ORM은 원격 데이터를 마치 로컬 인 것처럼 작업하도록 안내하므로주의를 기울이지 않으면 성능 문제가 발생할 수 있습니다.

SP를 완전히 사용한 상황에서 DB가 데이터 API를 제공하고 사용했습니다. 그 특정 응용 프로그램은 매우 큰 규모였으며 놀랍도록 잘 수행되었습니다. 그 후 SP에 대해 나쁜 말을하지 않을 것입니다!

또 다른 장점이 있습니다. DBA는 모든 SQL 쿼리를 작성하고 DB의 모든 관계형 계층 구조를 행복하게 처리하므로 필요하지 않습니다.

개발자가 ORM 객체를 도메인 모델로 잘못 사용하는 경우가 종종 발생합니다.

이것은 올바르지 않으며 도메인을 DB 스키마에 직접 연결합니다.

실제로 필요한 것은 ORM 계층을 원하는만큼 풍부하고 별도로 사용하는 별도의 도메인 모델입니다.

즉, 각 개체 집합간에 매핑이 필요합니다.

도메인 개체를 채울 수 있지만 원하는 경우 최대 절전 모드를 사용하지 않아도됩니다. 적절한 용어는 data-mapper 라고 생각합니다 . 지속 된 데이터가 도메인 개체와 완전히 다른 구조 일 수 있습니다.