여러 DataContexts

Question

시나리오 :

내가 로컬 네트워크 설정을 통해 실행하는 데스크톱 응용 프로그램을 수행하는 임무를하고있는 데이터베이스 및 백 오피스 부분이 존재해야한다는 등 POS 클라이언트가 서버에 대한 호출을 작성하는 동안 서버에서 작동합니다.

데이터베이스에 8 개의 스키마가있는 64 개의 테이블이 있으며, 한 스키마의 테이블은 다른 스키마 테이블간에 관계가 있습니다.

스키마

1. 계정 (계정의 차트, 거래, 저널, 은행/현금/예금 바우처)
2. 인적 자원 (부서 & 종업원)
3. 구매 (PO, PO 세부 사항, 구입은 &를 돌려줍니다 세부 사항)
4. 판매 (판매, 판매 세부, 판매 반환 & 세부 사항, 고객)
5. 재고 (생산 t, 재고, 비용의 변화에 ​​대한 역사, 가격, 재고 전송)
6. 세금 (세금 그룹, WHT 세금 등 GST)
7. 보안 (사용자, 권한 및 세션의 로깅)
8. 스토어 (스토어 프로필, 터미널, 절, 랙, 선반, 빈)

참고 : 네트워크에서 실행하는 그런 큰 데이터베이스에 대한 하나의 DataContext를 사용하는 우려가있다, 그 모델을 통해 그 탐색이 악화 것 응용 프로그램의 성능. 따라서 우리는 데이터 컨텍스트를 분류해야합니다. 직관적 인 전략은 데이터베이스의 각 스키마에 대해 하나의 DataContext (이 경우 8)를 만들고 서비스 계층을 통해 다른 컨텍스트와 데이터를 교환하는 것입니다. 내 디자인은 DDD를 기반으로합니다.

질문 : 주어진 시나리오에 대해 DataContext를 분류하는 적절한 전략은 무엇이라고 생각합니까? 이 문제에 대한 경험 많은 통찰력을 배우고 싶습니다.

추신. .NET Framework 4.0에서 Entity Framework 5.0을 클라이언트로 사용해야합니다.

Answer 1

도메인/비즈니스 지식은 데이터 컨텍스트의 분류를 정의하는 데 중요 할 것입니다. DDD에서는 Single Responsibility Principle을 사용하여 하위 도메인 (비즈니스 기능)을 별도의 제한된 컨텍스트로 구분할 수 있습니다. 그것은 POC에 좋지만 프로덕션에서는 레거시 시스템 (현재의 시스템)을 또 다른 제한된 컨텍스트로 간주해야합니다. 그냥 생각.