데이터베이스 특정 ID를 저장소 패턴으로 추출 하시겠습니까?

저는 DDD (도메인 기반 디자인)와 저장소 패턴 (C#)을 배우고 있습니다. 저장소 패턴을 사용하여 엔티티를 유지하고 실제로 사용되는 데이터베이스 (Oracle, MySQL, MongoDB, RavenDB 등)를 신경 쓸 필요가 없습니다. 그러나 데이터베이스 고유 ID를 처리하는 방법을 잘 모릅니다 : 대부분의 (모든?) 데이터베이스가 사용합니다. 예를 들어, RavenDB는 저장해야하는 각 엔티티에 string 유형의 id 속성이 있어야합니다. 기타에는 int 유형의 id 속성이 필요할 수 있습니다. 이것은 다른 데이터베이스에 의해 다르게 처리되기 때문에 데이터베이스 ID를 엔티티 클래스의 일부로 만들 수 없습니다. 그러나 적어도 실제 엔티티를 저장할 때는 어느 시점에 존재해야합니다. 내 질문은 이것에 관한 가장 좋은 방법은 무엇입니까?데이터베이스 특정 ID를 저장소 패턴으로 추출 하시겠습니까?

현재 내가 추구하고있는 아이디어는 각 비즈니스 개체 유형에 대해 데이터베이스 특정 "값 개체"를 구현하려는 각 데이터베이스에 대한 것입니다. 이 값 객체는 데이터베이스 고유의 id 속성을 가지며 읽기와 쓰기가 수행 될 때 두 객체 사이를 매핑합니다. 이게 좋은 생각 인 것 같니?

출처

2011-08-11 David Nordvall

정말 필요하니? 당신이 마주 치게 될 유지 보수 지옥 때문에 나에게 좋은 생각이 아닌 것 같습니다. – xelibrion

여기 xelibrion에 동의합니다. – NotMe

나는 똑같은 문제에 직면 해있다. 불행히도, 여기에 언급 된 해결책 중 어느 것도 나를 "완벽한 해결책"으로 치지 않습니다 (하나가 있다면 ...). 또한 데이터 추상화 계층 내에서 특정 구현 유형으로 변환하는 것을 고려했습니다. 말하자면'DTO'와'DAO'는 모든 DB 타입에 공통적 인 인터페이스이지만, 어떤 특정한'DAO' 구현체는 그 메소드 내에서'DTO'를 같은 특정 구현 유형으로 캐스팅 할 것입니다 한 번에 하나의 DB 유형 만 사용된다고 가정). 이렇게하면 특정 ID를 사용할 수 있습니다. 그것은 더러워 보이지만, 지금까지 생각해 낸 것이 최고입니다. – eitanfar

잠재적으로 엔티티에 ID를 가질 수는 있지만 엔티티의 공용 인터페이스의 일부로 볼 수는 없습니다. 이것은 테이블 컬럼을 private 필드에 매핑 할 수 있기 때문에 NHibernate에서 가능하다. 당신의 영속 로직이 비즈니스 로직에 '출혈'하지만 요구 사항 아마 엔티티 사이에 매핑을 유지하는 것보다 더 쉽고 강력을 부여하기 때문에

그래서 당신은 가능성이 적합하지 않습니다

class Customer { 
     private readonly Int32? _relationalId; 
     private readonly String? _documentId; 
     ...

같은 것을 가질 수는 이드는 외부 엔티티 어딘가에있다. 또한 관계형 데이터베이스 만 지원하려는 경우보다 현실적인 "데이터베이스 무신론자"접근 방식을 평가하는 것이 좋습니다. 이 경우 적어도 저장소 구현을 위해 NHibernate와 같은 ORM을 재사용 할 수 있습니다. 대부분의 관계형 데이터베이스는 동일한 id 유형을 지원합니다. 시나리오에서 ORM이 필요할뿐만 아니라 "Object-Document-Mapper"와 같은 것이 필요합니다. 톤과 톤의 인프라 코드를 작성해야한다는 것을 알 수 있습니다. 요구 사항을 재평가하고 관계형 데이터베이스와 문서 데이터베이스 중에서 선택하는 것이 좋습니다. 읽기 : Pros/cons of document-based databases vs. relational databases

출처

2011-08-11 17:21:24 Dmitry

이것은 추상적 인 경우의 누출입니다. 저장소 인터페이스 아래에서 각 데이터베이스와 함께 제공되는 좋은 점을 모두 잃어 버리기 전에는 데이터베이스 유형을 추상화 할 수 없습니다. ID 유형 (string, Guid 또는 기타)에 대한 요구 사항은 거대한 빙산의 맨 위에 있고 대부분은 진흙탕 아래에 있습니다.

트랜잭션 처리, 동시성 및 기타 사항에 대해 생각하십시오. 나는 끈기에 대한 당신의 요지를 이해하지 못합니다. 도메인 모델의 특정 데이터베이스 기술에 의존하지 않는 것이 좋습니다. 그러나 당신은 또한 모든 지속성 기술에 대한 의존성을 제거 할 수 없습니다.

도메인 모델을 모든 RDBMS에서 사용하기가 비교적 쉽습니다. 대부분은 표준화 된 데이터 유형을 가지고 있습니다. NHibernate와 같은 ORM을 사용하면 많은 도움이됩니다. NoSQL 데이터베이스 사이에서 동일한 것을 달성하는 것이 훨씬 더 어렵습니다 (실제로는 매우 좋습니다).

그렇다면 가능한 지속성 기술 집합에 대해 조사한 다음 지속성 하위 시스템에 대한 적절한 수준의 추상화를 선택하는 것이 좋습니다.

이 방법을 사용할 수 없다면 Event Sourcing을 생각해보십시오. 이벤트 저장소는 가장 까다로운 지속성 기술 중 하나입니다. Jonathan Oliver의 과 같은 라이브러리를 사용하면 사실상 파일 시스템을 포함한 모든 스토리지 기술을 사용할 수 있습니다.

출처

2011-08-12 06:41:01

아니요, 이것은 반대입니다 - 새는 추상화를 피하는 고전적인 경우입니다. 상점의 ID 유형을 오브젝트에 대한 글로벌 '우호적 인'참조로 사용하면 새어 나옵니다. ID를 유지하고 일반적으로 필요한 저장소를 계속 만듭니다. 보통 2 가지가 행복하게 일치합니다. 이 갈라진 금은 두 가지를 분리하려고 시도하기 때문에이 문제를 해결해야합니다. – Chalky

@Chalky DB와 같은 주요 API 제공 업체의 경우 너무 많은 추상화가 (거의 항상) 존재하지 않습니다. DB 유형을 너무 많이 사용하여 코드에서 특정 ID 유형을 사용하면 DB를 변경할 수 없게됩니다 ... 실제로는 영원히! 기업들은 DB가 데이터로 가득 차면 DB를 다른 DB로 대체하는 것을 꺼려합니다. 왜냐하면 대부분의 경우 데이터가 가득 차 있기 때문이며, 대부분의 경우, 소프트웨어의 완전히 새로운 구현을 제공하기도합니다. 특정 ID 유형을 가정합니다. – eitanfar

엔티티에서 int Id 필드를 만든 다음 저장소에서 Id가 문자열이어야하는 문자열로 변환합니다. 나는 당신의 끈기를 추상화하려는 노력이 매우 가치 있다고 생각하며 실제로 유지 보수를 용이하게합니다.

출처

2011-11-29 17:22:28 cdaq

당신은 바로 일을하고 있습니다! 데이터베이스 기본 키 유형의 제약에서 벗어나 자신을 추상화하십시오!
형식을 변환하지 마십시오. 다른 필드를 사용하십시오.

특히 : 데이터 액세스 논리를 제외하고는 데이터베이스의 기본 키를 사용하지 마십시오. 객체에 친숙한 ID가 필요한 경우 원하는 유형의 추가 필드를 만들고 데이터베이스에 저장해야합니다. 데이터 액세스 계층에서만 &이 개체의 알기 쉬운 ID를 기반으로 DB 레코드를 업데이트해야합니다. 쉬운.

그런 다음 개체를 유지할 수있는 데이터베이스에 대한 제약이 'xxxx 유형의 기본 키를 가질 수 있어야합니다'에서 'xxxx 유형을 저장할 수 있어야 함'으로 변경되었습니다. 나는 당신이 세계의 모든 데이터베이스를 사용할 수 있다고 생각합니다. 해피 코딩! DDD가 최고입니다!

출처

2014-07-15 23:36:01 Chalky

나는 같은 질문을하고있다. 당신이 제안하는 것이 내 마음에 처음으로 나온 것입니다. 그래도 버그에 관한 유일한 점은 DB에있는 거의 모든 객체에 두 개의 다른 ID 유형 필드를 만들 수 있다는 것입니다. – eitanfar

데이터베이스 특정 ID를 저장소 패턴으로 추출 하시겠습니까?

답변

관련 문제