使用实体框架

Question

背景

我正在考虑构建Saas应用程序的选项，该应用程序将在三个国家/地区提供（可能更晚）。它将在AWS上与RDS Postgres一起运行。实体框架核心是应用程序逻辑中的ORM，但任何ORM都可以考虑这个问题。

为了记录，这是我第一次构建具有这种复杂性的数据层，并且难以找到好的资源（我猜测这是由于跨区域数据处理的困难性质）。 / p>

候选人架构

我目前正在评估在澳大利亚运行主数据库的适用性，然后为美国和英国应用服务器创建只读副本（从属）。然后显然需要从美国和英国的应用程序服务器向澳大利亚大师发送书面文件。

将此体系结构与实体框架

一起使用的三种可能方式

• A）具有副本连接字符串的DbContext从副本读取以将实体提取到上下文中。然后突变实体属性。为了保存这些突变，我然后将它们附加到“更新”状态以分离DbContext，用主连接字符串实例化，然后该上下文在保存时执行写入澳大利亚的主服务器。
• B）对于所有创建/更新/删除操作，实体都是使用单个上下文从主数据库读取和写入的。
• C）对于所有操作，使用单个DbContext，并使用副本连接字符串进行实例化。然后从本地副本读取实体，然后在上下文中调用save时，它将它们发送到副本，但AWS会在幕后自动将任何创建/更新/删除操作路由到主数据库。

对这些用例的考虑

其中我最喜欢 A ，因为当实体断开连接时，你失去了一半实体框架的功能，然后你必须手动管理它们的状态。

B 似乎是最简单的，但 C 似乎是最好的权衡（如果它甚至可能？），因为您在读取时获得较低的延迟。但是，现在我不确定从一个数据库读取并写入另一个数据库的可能问题。或者由于我对这个主题的早期了解，我没有看到的东西。

如果有人在这里有任何经验/建议或更好的选择，我将不胜感激？

Answer 1

我从来没有尝试过，但是您可以封装或继承dB上下文并覆盖save changes调用。然后，您可以将只读副本的dbcontexts更改跟踪程序中的所有实体复制到与写入db关联的内部db上下文中。这将是相对简单和通用的，然后将它们全部复制回只读副本变更跟踪器。这种方法的缺点是在各个dbcontext中的更改跟踪器之间来回复制实体所需的开销。