具有跨模式关系的数据库的多个 DataContexts答案

【问题标题】：Multiple DataContexts for a database with cross-schema relationships具有跨模式关系的数据库的多个 DataContexts
【发布时间】：2017-01-19 11:37:22
【问题描述】：

场景：

我的任务是做一个桌面应用程序，它必须在本地网络设置上运行，这样数据库和后台部分必须驻留在服务器上，而 POS 客户端调用服务器进行操作。

数据库中有 64 个表，有 8 个 Schema，其中一个 Schema 中的表与其他 Schema 的表之间存在关系。

架构

账户（会计科目表、交易、日记帐、银行/现金/存款凭证）
人力资源（部门和员工）
采购（采购订单、采购订单详细信息、采购退货和详细信息）
销售（销售、销售详情、销售退货和详情、客户）
库存（产品、库存、成本、价格、库存变化的历史转移）
税（税组、WHT 税、GST 等）
安全性（针对用户、权限和会话的日志记录）
商店（商店简介、终端、部分、货架、货架、箱）

注意事项： 有人担心，对于必须在网络上运行的如此大的数据库使用一个 DataContext，通过该模型进行导航会降低应用程序的性能。因此，我们应该分解数据上下文；一个直观的策略是为数据库中的每个 Schema 创建一个 DataContext（在本例中为 8 个），并通过服务层与其他上下文交换数据。我的设计基于 DDD。

问题： 您认为针对给定场景分解 DataContext 的适当策略应该是什么？我想了解有关该问题的经验丰富的见解。

PS。我正在使用 Entity Framework 5.0 而不是 .NET Framework 4.0 作为客户端所需的。

【问题讨论】：

我不认为性能会成为问题，但由于架构和维护原因，我会分解上下文。您建议的每个设计部分一个上下文对我来说似乎是一种合适的方法。

标签： c# entity-framework domain-driven-design ddd-repositories

【解决方案1】：

您的领域/业务知识对于定义数据上下文的细分同样重要。在 DDD 中，您可以使用单一职责原则将子域（业务能力）分离到单独的有界上下文中。这对 POC 有好处，但我希望在生产中您需要将遗留系统（当前产品系统）视为另一个有界上下文。只是一个想法。

【讨论】：

当前系统将替换为我们正在开发的系统。