여러 데이터베이스가 동일한 DAL을 공유해야합니까?

Question

여러 데이터베이스에 접근해야하는 응용 프로그램이 있습니다. 이전에는 하나의 데이터베이스에만 접근 할 수있는 별도의 DAL이있었습니다. 별도의 비즈니스 계층은 특정 DAL에만 도달 할 수 있습니다. 비즈니스 계층의 최상위에 위치하는 응용 프로그램 (다른 웹 사이트)은 데이터를 공유해야하는 경우 여러 비즈니스 계층을 자유롭게 호출 할 수있었습니다.

잠시 동안 제대로 작동했습니다. 그러나 요즘 응용 프로그램을 작성하는 솔루션은 엄청나게 커졌습니다. 응용 프로그램 계층은 모든 비즈니스 계층을 터치하는 것처럼 보입니다. 재사용이 진행되고 있지만 빌드가 느려져서 단일 솔루션으로 가져 오는 불필요한 코드의 양이 부당하게 보입니다.

다른 사람이이 상황을 처리 한 사람이 있습니까? 나중에 LLBLGen 또는 NHibernate와 같은 ORM을 사용하여 데이터 공유를 DAL로 가져 왔습니까? 아니면 완전히 다른 것을 생각해 냈습니까?

Answer 1

아키텍처는 재사용 성, 모듈화 및 확장 성을 제공하는 모범 사례입니다. 그러나 이러한 목표를 달성하는 균형을 잃을 수 있습니다. 살펴볼 사항 중 하나는 수직 Business Logic - DAL 스택의 크기와 크기가 필요하다는 것입니다. 귀하의 모듈을보고 좋은 이유를 생각해보십시오. 특정 모듈이 서로 분리되어 있습니다. 고객이 확장 성을 위해 별도로 배포해야합니까, 아니면 별도로 판매해야합니까?

수직 분리에 대한 좋은 근거를 찾을 수없는 경우 일부 모듈을 병합하고 BL 및 DAL을 공유 할 수있는 더 큰 모듈로 이동할 수 있습니다. 모듈의 입도가 증가하여 오버 헤드가 줄어 듭니다.

또한 BL과 DAL 사이에 언급 된 수평 분리를 검토 할 수 있지만 대개 대규모 환경에서 별도의 계층에 배포되는 데이터 부분의 논리를 분리 할 수있는 목적을 달성하는 데 확실히 도움이됩니다. 또한 BL 모듈을 사용하여 필요한 모든 DAL 모듈을 호출 할 수는 있지만 Entity DB 매퍼와 함께 사용하면 데이터베이스 확장이 복잡해집니다. 이는 테이블이 여러 서버로 분할되는 경우 데이터베이스에 대한 다중 연결을 지원해야하기 때문입니다.

내 개인적인 접근 방식은 BL - DAL 조합의 세분성을 살펴보고 그 중 일부를 결합 할 수 있는지 확인하여 좋은 물건을 많이 잃지 않고 오버 헤드를 줄입니다. 그리고이 모든 모듈을 가지고 있다면 모듈 그룹당 빌드를 병렬화 할 수 있다고 생각합니다. 이점은 모듈화 된 아키텍처의 이점입니다. 왜 안돼?

Answer 2

Kroonwijk은 많은 장점을 제공합니다.

DAL 구현이 (일반적으로) 상호 작용하는 실제 데이터 소스와 연결된다는 것을 잊지 마십시오. 이는 BL과 DAL 간의 상호 작용을 정의하는 계약과는 다릅니다.