새로운 응용 프로그램과 상호 작용해야하는 기존 데이터베이스가 있습니다. 이전 데이터베이스는 지나치게 표준화되었고 일반적으로 잘못 설계되었습니다. 예를 들어 내 도메인에있는 하나의 개체는 데이터베이스에 5 개의 테이블을 나타냅니다. 도메인 계층에 기존 데이터베이스의 아티팩트가 없도록하고 싶습니다. 여기에 어떤 패턴을 사용해야합니까?내 저장소에 논리가 너무 많습니까?
언뜻보기에는 저장소 패턴에 대해 생각합니다. 내 개체를 리포지토리에 전달하고 데이터를 5 개의 테이블로 분할 처리하도록합니다. 그러나 수행해야하는 모든 매핑이 너무 많은 논리를 저장소에 추가하는 것이 좋습니다. 그래서 저장소에 나쁜 선택을 했습니까? 다른 패턴 (예 : 어댑터)을 사용하여 저장소를 사용해야합니까? 또는이 상황에서 저장소가 올바른 선택입니까?
리포지토리 패턴은 여기에 적합하지만 DanP가 제안한대로 Data Mapper을 사용하면 단일 책임 원칙을 준수하는 데 도움이됩니다. Hibernate와 Entity Framework와 같은 ORM은 일반적으로 Data Mapper의 역할을 용이하게하지만 데이터 저장소가 ORM을 사용하지 않는 경우이 논리를 직접 구현하는 것이 적절할 수 있습니다.
Jeff Morris는 Repository 패턴 here 컨텍스트 내에서 Data Mapper를 사용하는 좋은 예를 제공합니다.
그러나 레코드의 경우 ORM 작업은 object-relational impedance mismatch을 연결하는 것입니다. 관계형 데이터베이스 스키마는 도메인 모델과 구조가 다른 경우가 많습니다. 데이터베이스는 다른 이유로 잘 설계되지 않았지만 실체와 테이블 간의 1 대 1 관계가 없으면 그 자체로 불량 설계의 지표로 이해되어서는 안됩니다. 데이터베이스가 응용 프로그램 도메인의 지속성 저장소로 간주되는 DDD 관점에서 볼 때 데이터베이스 은이 제공되도록 작성된 원래 도메인에 대해 적절히 표준화되었습니다.
게이트웨이 패턴이 도움이 될 수 있습니까? 이전 데이터베이스에 대한 게이트웨이를 작성하십시오. 모든 변환 논리를 게이트웨이에 배치하십시오.
나는 Data Mapper 패턴이 당신이 무엇을하고 있는지 생각합니다. 덧붙여서 Davy Brion이 데이터 액세스를 this series of posts에서 손수 롤링하는 것에 대한 몇 가지 통찰력을 얻을 수 있습니다.
나는 더러운 일을 직접하려고하는 대신 NHibernate와 같은 것을 바라 보지 않겠습니까?
datamapper를 참조하는 그 기사는 매우 유익했습니다 +1 – DanP