여러 데이터베이스가있는 데이터 액세스 레이어 설계

Question

여러 데이터베이스가있는 문제와 관련하여 많은 게시물을 읽었으며이 경우 DAL을 효율적으로 설계하는 방법을 설명했습니다. 대부분의 경우, 포럼은 대부분의 경우에 잘 작동하는 저장소 패턴을 적용 할 것을 제안합니다.

그러나 나는 다른 상황에 처해 있습니다. Oracle, OLE DB 및 SQLServer의 3 가지 데이터베이스가 있습니다. 현재 여러 개의 클래스가있는 고유 한 DAL이있어 해당 데이터베이스에서 실행하기 위해 아래의 계층으로 SQL 쿼리를 보냅니다. 시스템이 작동하는 방식은 두 개의 데이터베이스가 정보를 읽는 데에만 사용되며 다른 하나는이 동일한 정보를 저장하거나 나중에 읽는 데 사용됩니다. 현재 구현에 더 나은 디자인을 제안해야하지만, 마치 세 가지 데이터베이스 모두에 대한 공통 인터페이스가 아키텍처 관점에서 그럴듯한 것처럼 보입니다.

이 상황을 해결할 수있는 디자인 패턴이 있습니까? 세 가지 DAL이 있어야합니까? 또는이 문제에 저장소 패턴을 적용하는 것이 가능할 수도 있습니다 (권장 할 만합니다).

Answer 1

질문에 대한 답변은 매우 주관적입니다. 이것들은 몇 가지 생각입니다.

명령 - 쿼리 분리를 적용 할 수 있습니다. 쿼리 측면은 비즈니스 또는 도메인 계층을 우회하여 데이터 계층과 직접 통합되며 반환하는 엔터티는 데이터베이스의 읽기 및 프로젝트에 맞게 최적화됩니다. 이 계층은 다른 데이터베이스 호출의 결과를 병합 할 수도 있습니다.

명령면은 R/W 데이터베이스에서 매핑되는 도메인 또는 비즈니스 엔티티를 사용하는 명령 핸들러로 구성됩니다.

이렇게하면 노출하는 인터페이스가보다 명확하고 비즈니스 지향적입니다.

데이터 액세스 레이어를 사용자 지정 작업 단위 및 저장소로 추상화하는 것이 정말로 필요하다고 확신하지 못합니다. 단점보다 장점이 더 큽니까? 그들은 거의 데이터베이스 기술을 바꿀 것이기 때문에 거의하지 않습니다. 그리고 그렇게한다면 어쨌든 재 작성을 의미 할 것입니다. 또한 엔티티 프레임 워크 코드를 먼저 사용하면 이미 작업 단위 (UOW)가 있고 데이터베이스의 추상화가 있습니다. LINQ 사용의 융통성.

결론 - 지나치게 엔지니어링하지 말고 지나치게 추상화하지 마세요. 또는 일을 슈퍼 제네릭으로 만들 수 있습니다.

Answer 2

핵심/업무 코드는 응용 프로그램의 DAL 계층에 배치 된 계약/인터페이스/클래스에 의존해서는 안됩니다.

데이터 액세스는 응용 프로그램의 비즈니스/핵심 계층에서 수행 할 수 있어야하며, SQL 문에 대한 종속성없이 기본 데이터 액세스 기술에 대한 지식이 없어도 수행 할 수 있어야합니다.

응용 프로그램의 핵심 부분에서 "SQL"문을 제거해야한다고 생각합니다. SQL은 공급 업체에 따라 다르며 특정 데이터베이스 엔진에 대한 종속성은 핵심을 벗어나서 속한 DAL로 이동해야합니다. 그런 다음 하나 이상의 DAL 모듈/클래스에서 구현 클래스를 만드는 DAL 외부에있는 인터페이스를 만들어야합니다. 귀하의 DAL은 귀하의 핵심 부분에 종속 될 수 있지만 그 반대가 아닙니다.

이 경우 리포지토리 계층을 사용할 수없는 이유는 알 수 없습니다. 필자 만 읽을 수있는 데이터베이스가있을 때 일반적으로 리포지토리 인터페이스의 이름에 ICompanyRepositoryRead와 같이이를 표시하도록합니다.