SPA 热毛巾：多数据库上下文答案

【问题标题】：SPA Hot Towel: Multiple Database ContextSPA 热毛巾：多数据库上下文
【发布时间】：2014-04-04 13:07:02
【问题描述】：

我是 SPA 热模板的新手，我正在尝试使用多个连接字符串（多个数据库上下文）。网上大部分例子只用了一个如下

[BreezeController]
public class MyController : ApiController
{
readonly EFContextProvider<ContextClass> _contextProvider =
new EFContextProvider<ContextClass>();

[HttpGet]
public string Metadata()
{
    return _contextProvider.Metadata();
}


[HttpPost]
public SaveResult SaveChanges(JObject saveBundle)
{
    return _contextProvider.SaveChanges(saveBundle);
}

...

在我使用存储库、工作单元并能够连接来自不同内容的对象的情况下，实现此类事情的最佳方式是什么？

【问题讨论】：

有多种方法可以处理这种情况，包括在具有多个 EntityManager 的客户端或服务器上。每个都有自己的好处和障碍，所以如果你能提供更多关于你正在尝试做什么以及上下文中的数据将如何关联的细节，这将是有帮助的。见link 斜体粗体 this.
谢谢。该链接很有帮助。我在上下文中有不同的表，它们可以连接到一个列上。客户端与服务器的优缺点是什么？我希望在服务器端进行加入和所有操作，在那里我也将使用存储库和工作单元。
表格是否存在于不同的上下文中？如果实体存在于相同的上下文中会更直接，因此请确保增加复杂性是值得的。
我有不同数据库中的表，每个数据库都有一个上下文。还有其他我想念的方法吗？

标签： c# single-page-application dbcontext hottowel

【解决方案1】：

让我们将 (1) Repo/Unit-of-Work 问题与 (2) 多数据库问题分开。

服务器端编码实践

您所描述的内容仅出现在演示中。服务器代码的存在是为了促进客户端开发故事，这是这些 BreezeJS 示例的重点。我们没有努力说明正确的服务器端编码实践。事实上，我们经常表现出不好的做法。

我们并不感到羞耻。我们希望您全神贯注于 Breeze 客户端。我们只需要一个功能性的服务器，而“正确地做”将需要更多的代码和干扰，而这与编写 Breeze 客户端无关。

为了记录，我永远不会在真实应用程序的控制器中创建EFContextProvider。控制器应该专注于调解客户端请求。它应该是瘦的。单独项目中的存储库或 UoW 类（和助手）将处理业务逻辑和持久性。

EFContextProvider 本身是生产级的，适用于将 Breeze 客户端请求转换为实体框架持久性操作的大多数应用程序。

多个数据库

如果你在服务器上完成所有的连接，你的 web api（小“w”，小“a”）可以向客户端呈现一个单一的面孔，你只需要一组元数据来描述一个模型跨多个数据库持续存在。这对于客户端开发非常有用，并且可能是最高效的方法，因为无论您在客户端上做什么，都必须在服务器上验证和协调跨数据库查询并保存操作。

无可避免的事实是，您的服务器将比拥有一个模型、一个 DbContext 和一个数据库的情况复杂得多。太糟糕了，您无法分离工作流，因此每个功能区域只有一个模型/上下文/数据库。您可能会失去使用IQueryable 的能力，并且必须为您的客户端应用程序所需的每个查询编写特定的端点。哦，好吧。

我闻到了更深层次的架构问题。但是现实世界向我们展示了臭名昭著的情况；如果可能的话，我们必须保持警惕并坚持下去。

至少您可以通过完全在服务器上管理混乱来屏蔽客户端。这就是我想要做的。

【讨论】：